views:

129

answers:

2

Some time ago I looked over Haskell docs and found it's functional composition operator really nice. So I've implemented this tiny decorator:

from functools import partial

class _compfunc(partial):
    def __lshift__(self, y):
        f = lambda *args, **kwargs: self.func(y(*args, **kwargs)) 
        return _compfunc(f)

    def __rshift__(self, y):
        f = lambda *args, **kwargs: y(self.func(*args, **kwargs)) 
        return _compfunc(f)

def composable(f):
    return _compfunc(f)

@composable    
def f1(x):
    return x * 2

@composable
def f2(x):
    return  x + 3

@composable
def f3(x):
    return (-1) * x

@composable
def f4(a):
    return a + [0]

print (f1 >> f2 >> f3)(3) #-9
print (f4 >> f1)([1, 2]) #[1, 2, 0, 1, 2, 0]
print (f4 << f1)([1, 2]) #[1, 2, 1, 2, 0]

The problem: without language support we can't use this syntax on builtin functions or lambdas like this:

((lambda x: x + 3) >> abs)(2)

The question: is it useful? Does it worth to be discussed on python mail list?

+6  A: 

IMHO: no, it's not. While I like Haskell, this just doesn't seem to fit in Python. Instead of (f1 >> f2 >> f3) you can do compose(f1, f2, f3) and that solves your problem -- you can use it with any callable without any overloading, decorating or changing the core (IIRC somebody already proposed functools.compose at least once; I can't find it right now).

Besides, the language definition is frozen right now, so they will probably reject that kind of change anyway -- see PEP 3003.

PiotrLegnica
compose() is not so clear. What is the direction of composition? You have to look at documentation to answer this question.
si14
@si14: Not knowing Haskell I don't find >> and << that clear either (does it mean insert or wrap the other function?).
nikow
@Nikow: I don't know it too, but >> and << clearly define the "computation flow": f1 >> f2 >> f3 means "put result of f1 to f2, then result of f2 to f3". Alternative is f1(f2(f3(x))) with a lot of messy braces.
si14
@si14: I see the logic in that, but still think that it is mostly a matter of habit. There is at least one functional language that makes excessive use of parentheses ;-)To me this sounds similar to the (Java-)people complaining that len(a) is not object oriented and should be a.len().
nikow
`>>` means something importantly different in Haskell. It's a special case of `>>=` which includes a kind of function composition, but also unpacking from a Monad. @si14: In fact I was assuming you meant f1>>f2 to be lambda x: f2(f1(x)). I see now why you construe it the way you do, but this is the opposite order as the mathematically familiar composition operator.
profjim
I know, but Python doesn't have |> operator so I redefined these.
si14
@nikow: this .len() thing is about design and >> is about syntax sugar. Quite different things :)
si14
I think that |> operator is not very readable. Python is not for every task. There are some things that Haskell and F# are better at.
Hamish Grubijan
I understand that Python is not a silver bullet. But in some cases this syntax would be nice IMHO.
si14
@si14: NO, `len(a)` in Python is syntactic sugar for `a.len()` (or more precisely `a.__len__()`).
nikow
+3  A: 

Function composition isn't a super-common operation in Python, especially not in a way that a composition operator is clearly needed. If something was added, I am not certain I like the choice of << and >> for Python, which are not as obvious to me as they seem to be to you.

I suspect a lot of people would be more comfortable with a function compose, the order of which is not problematic: compose(f, g)(x) would mean f(g(x)), the same order as o in math and . in Haskell. Python tries to avoid using punctuation when English words will do, especially when the special characters don't have widely-known meaning. (Exceptions are made for things that seem too useful to pass up, such as @ for decorators (with much hesitation) and * and ** for function arguments.)

If you do choose to send this to python-ideas, you'll probably win a lot more people if you can find some instances in the stdlib or popular Python libraries that function composition could have made code more clear, easy to write, maintainable, or efficient.

Mike Graham