Jason Baker <[email protected]> added the comment:
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. :-)
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue11011>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
