Overall, I have no major objections to the PEP or the patch. Before it goes in on auto-pilot, it would be darned nice if the proponents said that they've found it helpful in real code and that they are satisfied with the timings.
I guess "darned nice" is the best you can hope for. Not sure if Peter Harris is still around.
Yes, I'm still lurking, slightly aghast that my little PEP is getting such ferocious scrutiny. I would have like some of that in time for it to go into 2.4, but I suppose you should be careful what you wish for.
I'll answer a few points from this thread, in no particular order:
My original desire was a built-in, but it was suggested that the first step would be a Python implementation in the standard library to try it out. That was the basis for the PEP, and in fact a C implementation would have been beyond my expertise.
However, I sympathise with anyone who feels unhappy about a new module just for what amounts to one function. I'd be happy to go back to the built-in, now someone cleverer than I am has written one. Sorry I can't rememeber your name, whoever you are. I'm having trouble with my e-mails.
I was never too bothered about efficiency, and still am not. For me it was always primarily a way to save typing or build call-back functions on the fly. The discussion about using it to make instancemethods and classmethods -- way over my head! I would count that as something weird enough to be worth spelling out in "plain Python", in my code anyway.
The PEP was scattered over a few patches because I wasn't too sure how to go about it, so there was my Python module, the C implementation, the unit tests and the docs all in separate patches. 3/4 of that was my fault - sorry!
Once the PEP had been accepted, I didn't like to mess with it, which is why I went quiet for a while.
It's gone past the point where I can personally contribute much, so I'd just like to say thanks and I look forward to the day when I can just use it.
Peter Harris firstname.lastname@example.org wrote:
However, I sympathise with anyone who feels unhappy about a new module just for what amounts to one function.
Well, since it seems that the emphasis in Python development is now moving more towards expanding the standard library, a module that has only one function now might grow more functions in the not so distant future, so I have to say that I'm on the side of not being unhappy with the added module. (I'm also secretly hoping that map, filter, reduce, etc. will be moved to the functional module in the future, maybe in Python 3.0. But that's probably just my love for list comprehensions and generator expressions speaking.) ;-)
Steven Bethard wrote:
(I'm also secretly hoping that map, filter, reduce, etc. will be moved to the functional module in the future, maybe in Python 3.0. But that's probably just my love for list comprehensions and generator expressions speaking.) ;-)
Given Guido's stated desire to get rid of those three, but also given the fact that sometimes they're just plain clearer than the equivalent list comp (e.g. performing a type conversion on an entire list), having the functional module as a place to eventually put them seemed like a fine idea to me.
I'm actually half-tempted to suggest that those three functions should be aliased in the functional module for 2.5 (in addition to being in builtins - ala the contents of the exceptions module).
I also agree with your other point - with a functional module in place, it becomes more feasible to give the functional programming folks a few extra tools without impacting too badly on those people that *aren't* interested in FP related stuff.
Cheers, Nick. Maybe we should open a book on the next method to make it into functional. Compose, perhaps?