UserLinux chooses Python as "interpretive language" of choice
skip at pobox.com
Sun Dec 21 05:31:51 CET 2003
John> On the other hand, claiming that sum() is an adequate replacement
John> for reduce() is so silly that it borders on the absurd.
>> No, operationally that's a correct statement. People have looked at
>> the use of reduce() in a number of different contexts. In all but
>> the rarest of cases, reduce() was used to sum a list of numbers.
>> sum() is a perfectly adequate replacement in all but those rare cases
>> and is easier to read as well. As Guido mentioned in the talk I
>> referenced above:
>> nobody uses it, few understand it
>> a for loop is clearer & (usually) faster
HV> I think no one even tries to understand the very concept of reducing
HV> sequence to a single object using a rule . Sum is not a replacement
HV> of this *concept*. Just what is so wrong with having such a general
HV> tool available in a programming language ? Doesn't it hurt to
HV> understand how to use it?
It doesn't hurt to understand the concept of reduce(), but if it's never (or
very rarely) used, it's just extra (nearly dead) code which has to be
maintained. It's easy enough to write reduce() in Python, and if/when PyPy
is a reality shouldn't be any less efficient than the current C version.
>> No, it's simply not used very much. Python never has been a very
>> strong functional language. It's always been a very strong
>> object-oriented language. Use it the way it's strongest.
HV> I think Guido should put his money where his mouth is and simply
HV> eliminate functions as first class objects then !
There are lots of use cases for functions as first class objects which don't
intersect with the usual notions of functional programming. Here's one
rather silly example:
l = 
append = l.append
for i in range(25):
Another less silly example is os.walk(). It's in some sense a specialized
map() function, so does overlap a bit more with the usual notion of
HV> If python ever gets very fast, people will reimplement things like
HV> reduce in their own code or in a functional module.
As well they should. It's a five-liner in Python. I've never used it for
anything but summing a list of numbers. That appears to be true of most
John> There is no replacement for lambda in sight, even though lambda is
John> arguably the ***largest single*** one of the functional constructs
John> that needs work, and has obviously needed work for a long time.
>> Once again, you desire Python to be something it is not. If you want
>> a strong functional language, program in Lisp or Haskell.
HV> Functions are supposedly first class, regular objects in python. Why
HV> can't they be sometimes anonymous, just like tuples, lists and user
HV> defined objects can ? One doesn't even need to consider other
HV> languages to make this point.
Having functions as first-class objects doesn't mean you have to be able to
define anonymous functions. Functions as first-class objects worked just
fine before Guido introduced lambda to the language in Python 1.0.
HV> Does anyone care about consistency in python ? For real, if you
HV> don't want functional programming, make functions non first class
HV> and stop claiming that they are objects just like every object.
As I indicated above, "functions as first-class objects" is not synonymous
with "functional programming". There are plenty of uses for function
objects without considering map(), apply(), lambda(), filter(), reduce() and
More information about the Python-list