However if these semantics were brought into the core language I'd be very happy.
Yeah, I admit part of me felt dirty implementing this by commandeering operators. But my brief time with Haskell and F# has biased me enough toward this style of function composition that I preferred to deal with the ugliness of my hack, rather than the ugliness of not being able to express certain functions in this style in my other toy projects. :)
I agree though, hopefully the language itself will support this one day, and then my ugly hack can go away. (I swear, Python always seems to stop just shy of being a fantastic little dynamic fp language...)
Thanks for the feedback!
+1 here, but I'm not holding my breath. Python's BFDL has been hostile to making lambda more powerful; I'm not sure what he would think about this.
I think the syntax is fine. The star operator already is sensitive to the operands, so you're not impairing readability at all.
Overloading these operators on function objects really isn't the end of the world. It's not like these operators were being used for anything, and sometimes this kind of DSL-ish extension can be good. It's certainly more reasonable than the goto module, which uses horrid bytecode hax to get the job done.
If you want this in the language, write to the python-ideas mailing list, and then draft a PEP if you get any support. Good luck!
There's going to be a lot of overhead with this kind of thing, but did you have another reason?
All that code is executing on every partial call. So, a very brief list of reasons not to use this in production:
4. don't fight the language
edited to add: I just want to emphasize that I think it's a really, really neat hack!
edit: In other words, "Don't fight the language" as another commenter said.
When I'll have time, I'll implement a web WSGI Web UI to provide visualization capability. My goal is to provide a programmer-friendly replacement to Pentaho Kettle.
http://exposedata.com/parallel/ (if upload fails, this is what it looks like)
Once I get the CSV uploader more robust, I'll add additional charts that respond to interactive filters/aggregators, just as the table responds to the chart above.
The goal is a data exploration tool for non-programmers, but I'm keen to extend it for programmers who need more sophisticated ETL and are willing to do a little scripting.
EDIT: That is, all these years at school I was taught to write f(x) = x^2, not f = (^2).
thing x = th . in . g x
x :: a
g :: a -> b -> c
in :: c -> d
th :: d -> e
thing :: a -> b -> e
thing x = th . in . g $ x
IMO, point free style is hard enough to understand in Haskell code, where it's used all the time and I'm expecting to see it. Coming across it in Python, where I'm not expecting it, would probably take me an hour just to figure out what you were trying to do.
Besides, you're not able to do all the point free stuff in python, you can't partially apply an infix function (there is no `map((+2), [1, 2, 3])`.
map(functools.partial(operator.add,2), [1, 2, 3])