Message127076
Ray, thanks for prompt and thorough feedback. To address your concerns:
* I'm fine with doing away with const and identity (long story short I haven't really used them in functional languages anyway). There were reasons for defining identity the way it is, but it's hardly a big deal if that doesn't make it in.
* Personally, I see the mathematical notation for compose to be very intuitive, however it's typically described in a non-intuitive manner. The functions get called in a left-to-right manner (as is intuitive), however, when you see it defined it is usually in a right-to-left manner. Thus it can be confusing because we say compose(f, g)(x) [left-to-right] is equivalent to g(f(x)) [which reads right-to-left, but is still doing what you might expect intuitively]. But I doubt most people that use Python will care about the mathematical usage anyway. What if we called the function "pipeline"? That's essentially what it's doing, and I think people would find that easier to understand.
* I'm not saying you're wrong about trampoline, but I want to make sure that you and I are discussing the same thing. :-) The idea for trampoline comes from clojure, which is unique among functional languages in that it has no tail-call recursion. Trampoline is a way to write a function that is tail recursive, but won't blow the stack. So your example, while similar isn't *quite* the same thing. The documentation I wrote shows an example function count_to_a_million. If I wrote it like this I'd blow the stack:
def count_to_a_million(i):
if i < 1000000:
return count_to_a_million(i)
else:
return i
Of course, you could definitely argue that it would just be easier to use a loop (or even better range). However, many functional programmers' brains have just been wired to use recursion which they might find more intuitive as a means of iteration. Of course, one could argue that it would be better for them to learn the Pythonic way of doing things, and I would agree. Python is a multi-paradigm language that supports both functional and imperative approaches, therefore it's Pythonic to provide a functional approach.
* It sounds like you feel flip is useful, but it's a matter of whether you feel it's useful enough to add to the standard library.
Lastly, I love list comprehensions and see where you're coming from, but why do the two have to be mutually exclusive? I mean, the idea for them came from Haskell which hasn't done away with them. For instance, take your example:
[f(g(2,x), h(x, 3, y, flag=True)) for x, y in zip(X, Y) if x>y//2]
I certainly hope you don't really write code like that. :-)
I think something like this is more readable:
fg = partial(compose(f, g), 2)
h1 = lambda x, y: h(x, 3, y, flag=True)
[(fg(x), h1(x, y)) for x, y in zip(X, Y) if x>y//2]
...but maybe I'm weird.
If you're still opposed to adding these functions, let me know. I feel that they have use-cases in the Python standard library, but I can add them to pysistence when I port it to Python 3 and make it a functional data structure/algorithm library. :-) |
|
Date |
User |
Action |
Args |
2011-01-26 00:34:08 | Jason.Baker | set | recipients:
+ Jason.Baker, rhettinger, eric.araujo |
2011-01-26 00:34:08 | Jason.Baker | set | messageid: <1296002048.21.0.378658284085.issue11011@psf.upfronthosting.co.za> |
2011-01-26 00:34:06 | Jason.Baker | link | issue11011 messages |
2011-01-26 00:34:06 | Jason.Baker | create | |
|