reduce() anomaly?

[Stephen C. Waterbury]

This seems like it ought to work, according to the
description of reduce(), but it doesn't. Is this
a bug, or am I missing something?

Python 2.3.2 (#1, Oct 20 2003, 01:04:35)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright" , "credits" or "license" for more information.

d1 = {'a':1}
d2 = {'b':2}
d3 = {'c':3}
l = [d1, d2, d3]
d4 = reduce(lambda x, y: x.update(y), l) Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 1, in <lambda>
AttributeError: 'NoneType' object has no attribute 'update' d4 = reduce(lambda x, y: x.update(y), l, {})

Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 1, in <lambda>
AttributeError: 'NoneType' object has no attribute 'update'

- Steve.

[Alan Kennedy]

[Robin Becker]

The whole 'only one way to do it' concept is almost certainly wrong.

[Alex Martelli] Bingo! You disagree with the keystone of Python's philosophy. Every
other disagreement, quite consequently, follows from this one.

[Douglas Alan] The "only one way to do it" mantra is asinine.

I hate to interrupt anybody's free flowing argument, but isn't it the
case that Guido never said "There should be only one way to do it"?

My understanding of the "Pythonic Philosophy" is that "there should be
only one *obvious* way to do it", which is quite a different thing
entirely.

This philosophy is aimed at making python easy for newbies: they
shouldn't get confused by a million and one different possible
approaches. There *should* (not "must"!) be a simple and obvious way
to solve the problem.

Once one is familiar with the language, and all of the subtle power it
encompasses, anything goes in relation to implementing an algorithm.

Just my €0,02.

--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan

[Dave Brueck]

> >> The whole 'only one way to do it' concept is almost certainly wrong.

Bingo! You disagree with the keystone of Python's philosophy. Every
other disagreement, quite consequently, follows from this one.

The "only one way to do it" mantra is asinine. It's like saying that
because laissez faire capitalism (Perl) is obviously wrong that
communism (FP) is obviously right. The truth lies somewhere in the
middle.

Part of the problem here is that just saying "only one way to do it" is a
horrible misquote, and one that unfortunately misses IMO some of the most
important parts of that "mantra":

c:\>python
Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on
Type "help", "copyright" , "credits" or "license" for more information.

import this

The Zen of Python, by Tim Peters
[snip]
There should be one-- and preferably only one --obvious way to do it.

-Dave

[Alex Martelli]

Robin Becker wrote:
...

Python's essence is simplicity and uniformity. Having extra features
in the language and built-ins runs directly counter to that.

no disagreement, reduce is in line with that philosophy sum is a
shortcut and as others have said is less general.

'sum' is _way simpler_: _everybody_ understands what it means to sum a
bunch of numbers, _without_ necessarily having studied computer science.

The claim, made by somebody else, that _every_ CS 101 course teaches the
functionality of 'reduce' is not just false, but utterly absurd: 'reduce',
'foldl', and similar higher-order functions, were not taught to me back when
_I_ took my first university exam in CS [it used Fortran as te main
language], they were not taught to my son in _his_ equivalent course [it
used Pascal], and are not going to be taught to my daughter in _her_
equivalent course [it uses C]. Google for "CS 101" and convince yourself
of how utterly absurd that claim is, if needed -- how small is the
proportion of "CS 101" courses that teach these subjects.

Python's purpose is not, and has never been, to maximize the generality
of the constructs it offers. For example, Ruby's hashes (and, I believe,
Perl's) are more general than Python's dicts, because in those hashes
you can use arbitrary mutable keys -- e.g., arrays (Ruby's equivalent of
Python's lists), strings (which in Ruby are mutable -- more general than
Python's strings, innit?), etc. Python carefully balances generality,
simplicity, and performance considerations. Every design is a series of
compromise decisions, and Python's design is, in my opinion, the best
one around (for my purposes) because those compromises are struck with
an _excellent_ batting average (not perfectly, but better than any other
language I've ever studied, or designed myself). The underlying idea
that there should preferably be ONE obvious way to express a solution
is part of what has kept Python so great as it evolved during the years.

The whole 'only one way to do it' concept is almost certainly wrong.

Bingo! You disagree with the keystone of Python's philosophy. Every
other disagreement, quite consequently, follows from this one.

not so, I agree that there ought to be at least one way to do it.

But not with the parts that I quoted from the "spirit of C", and I
repeat them because they were SO crucial in the success of C as a
lower-level language AND are similarly crucial in the excellence of
Python as a higher-level one -- design principles that are *VERY*
rare among computer languages and systems, by the way:

Keep the language small and simple.

Provide only one way to do an operation.

"Only one way" is of course an _ideal_ goal (so I believe the way
it's phrased in Python, "preferably only one obvious way") -- but
it's a guiding light in the fog of languages constructed instead
according to YOUR completely oppposite goal, and I quote you:

There should be maximal freedom to express algorithms.

Choose just about every OTHER language on Earth, and you'll find
it TRIES (with better or worse results depending on how well or
badly it was designed, of course) to meet your expressed goal.

But NOT Python: you're using one of the _extremely few_ languages
that expressly do NOT try to provide such "maximal freedom", that
try instead to stay small and simple and provide (preferably)
only one (obvious) way to do an operation. Your choice of language
is extremely peculiar in that it _contradicts_ your stated goal!

Want "maximal freedom to express algorithms"? You can choose among

... you may be right, but I object to attempts to restrict my existing
freedoms at the expense of stability of Python as a whole.

Nobody restricts your existing freedom of using Python 2.3.2 (or
whatever other release you prefer) and all of its constructs and
built-ins; nobody ever proposed retroactively changing the license
to do that (and I doubt it could be done even if anyone wished!).

But we're talking about Python 3.0, "the point at which backwards
compatibility will be broken" -- the next _major_ release. To quote
Guido, in 3.0 "We're throwing away a lot of the cruft that Python has
accumulated." After a dozen years of backwards compatible growth,
Python has a surprisingly small amount of such cruft, but it definitely
does have some. Exactly _what_ qualifies as 'cruft' is not yet decided,
and it won't be for quite a while (Guido thinks he won't do 3.0 until
he can take PSF-financed time off to make sure he does it right). But
there is no doubt that "reduce feature duplication" and "change rules
every so slightly to benefit optimization" _are_ going to be the
themes of 3.0.

Python can't keep growing with great new ideas, _AND_ still be a
small and simple language, without shedding old ideas that do not
pull their weight any more, if they ever did. Check out, e.g.,
the "python regrets" talk of well over a year ago,
http://www.python.org/doc/essays/ppt...honRegrets.ppt
to see that lambda, map, filter, and reduce are all among those
regrets -- things that Guido believe he never should have allowed
in the language in the first place. E.g., and I quote from him:

"""
reduce()
nobody uses it, few understand it
a for loop is clearer & (usually) faster
"""

and that was way BEFORE sum took away the vast majority of reduce's
use cases -- so, guess how he may feel about it now...?

One of Python's realities is that _Guido decides_. Not without lots
of pressure being put on him each and every time he does decide, of
course -- that's part of why he doesn't read c.l.py any more, because
the pressure from this venue had gotten way excessive. Of course,
he's going to be pressured on each and every one of the items he
mentions in detail in the "regrets" talk and more summarily in the
Python 3.0 "State of the Python Union" talk. But I'm surely not the
only one convinced that here, like in (by far) most difficult design
decisions in Python's past, he's on the right track. Python does
need to keep growing (languages that stop growing die), but it must
not become big, so it must at long last lose SOME of the accumulated
cruft, the "feature duplication".

I'll deeply regret, come Python 3.0, not being able to code
"if blah(): fleep()"
on one single like any more, personally. And I may try to put on
pressure for a last-minute reprieve for my own pet "duplicated
feature", of course. But in the end, if I use Python it's because
I believe Guido is a better language designer than I am (and that
most other language designers are), so I will accept and respect
his decisions (and maybe keep whining about it forevermore, as I
do for the "print>>bah,gor p" one:-).

But can't you let us have *ONE* language that's designed according

I am not attempting to restrict anyone or change anyone's programming
style. I just prefer to have a stable language.

I think Python's stability is superb, but stability cannot mean that
there will never be a 3.0 release, or that the language will have to
carry around forever any mistaken decision that was once taken. I'm
not advocating a "high level of churn" or anything like that: we have
extremely "sedate" and stable processes to gradually deprecate old
features. But such deprecation _will_ happen -- of that, there is
most definitely no doubt.
Alex

[Douglas Alan]

"Dave Brueck" <da**@pythonapo crypha.com> writes:

Part of the problem here is that just saying "only one way to do it" is a
horrible misquote, and one that unfortunately misses IMO some of the most
important parts of that "mantra":

Well, perhaps anything like "only one way to do it" should be removed
from the mantra altogether, since people keep misquoting it in order
to support their position of removing beautiful features like reduce()
from the language.

|>oug

[Dave Brueck]

> > Part of the problem here is that just saying "only one way to do it" is
a

horrible misquote, and one that unfortunately misses IMO some of the most important parts of that "mantra":

Well, perhaps anything like "only one way to do it" should be removed
from the mantra altogether, since people keep misquoting it in order
to support their position of removing beautiful features like reduce()
from the language.

You're joking, right? It is one of the key aspects of Python that makes the
language such a good fit for me. Changing the philosophy because a *few*
people don't "get it" or because they are apt to misquote it seems crazy.

-Dave

P.S. If reduce() were removed, none of my code would break. ;-)

[Douglas Alan]

"Dave Brueck" <da**@pythonapo crypha.com> writes:

> Part of the problem here is that just saying "only one way to do
> it" is a horrible misquote, and one that unfortunately misses IMO
> some of the most important parts of that "mantra":

Well, perhaps anything like "only one way to do it" should be removed
from the mantra altogether, since people keep misquoting it in order
to support their position of removing beautiful features like reduce()
from the language.

You're joking, right? It is one of the key aspects of Python that makes the
language such a good fit for me. Changing the philosophy because a *few*
people don't "get it" or because they are apt to misquote it seems crazy.

Of course I am not joking. I see no good coming from the mantra, when
the mantra should be instead what I said it should be: "small, clean,
simple, powerful, general, elegant" -- not anything like, "there
should be only one way" or "one right way" or "one obviously right
way". I have no idea what "one obviously right way" is supposed to
mean (and I don't want to have to become Dutch to understand it)
without the language being overly-restricted to the point of
uselessness like FP is. Even in FP, I doubt that there is always, or
even typically one obviously right way to accomplish a goal. To me,
there is never *one* obviously "right way" to do anything -- the world
(and the programming languages I chose to use) offer a myriad of
possible adventures, and I would never, ever want it to be otherwise.

|>oug

[David Eppstein]

In article <lc************ @gaffa.mit.edu> ,
Douglas Alan <ne****@mit.edu > wrote:

"Dave Brueck" <da**@pythonapo crypha.com> writes:

Part of the problem here is that just saying "only one way to do it" is a
horrible misquote, and one that unfortunately misses IMO some of the most
important parts of that "mantra":

Well, perhaps anything like "only one way to do it" should be removed
from the mantra altogether, since people keep misquoting it in order
to support their position of removing beautiful features like reduce()
from the language.

I think the more relevant parts of the zen are:
Readability counts.
Although practicality beats purity.

The argument is that reduce is usually harder to read than the loops it
replaces, and that practical examples of it other than sum are sparse
enough that it is not worth keeping it just for the sake of
functional-language purity.

--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science

[Dave Brueck]

> >> > Part of the problem here is that just saying "only one way to do

> it" is a horrible misquote, and one that unfortunately misses IMO
> some of the most important parts of that "mantra": Well, perhaps anything like "only one way to do it" should be removed
from the mantra altogether, since people keep misquoting it in order
to support their position of removing beautiful features like reduce()
from the language.

You're joking, right? It is one of the key aspects of Python that makes

the language such a good fit for me. Changing the philosophy because a *few*
people don't "get it" or because they are apt to misquote it seems

crazy.
Of course I am not joking. I see no good coming from the mantra, when
the mantra should be instead what I said it should be:
Nah, I don't really like your version. Also, the "only one way to do it"
misquote has been singled out when it really should be considered in the
context of the other items in that list - for whatever reason (maybe to
contrast with Perl, I don't know) it's been given a lot of weight in c.l.py
discussion threads.
"small, clean, simple, powerful, general, elegant"
It's really a matter of taste - both "versions" mean about the same to me
(and to me both mean "get rid of reduce()" ;-) ).
To me, there is never *one* obviously "right way" to do anything

Never? I doubt this very much. When you want to add two numbers in a
programming language, what's your first impulse? Most likely it is to write
"a + b". The same is true of a lot of other, even much more complex, things.
And IMO that's where this principle of an obvious way to do things comes
into play, and it's tightly coupled with the principle of least surprise. In
both cases they are of course just guiding principles or ideals to shoot
for, so there will always be exceptions (not to mention the fact that what
is obvious to one person isn't universal, in the same way that "common
sense" is rarely common).

Having said that though, part of the appeal of Python is that it hits the
nail on the head surprisingly often: if you don't know (from prior
experience) how to do something in Python, your first guess is very often
correct. Correspondingly , when you read someone else's Python code that uses
some feature you're not familiar with, odds are in your favor that you'll
correctly guess what that feature actually does.

And that is why I wouldn't be sad if reduce() were to disappear - I don't
use reduce() and _anytime_ I see reduce() in someone's code I have to slow
way down and sort of rehearse in my mind what it's supposed to do and see if
I can successfully interpret its meaning (and, when nobody's looking, I
might even replace it with a for-loop!). Of course that would be different
if I had a history of using functional programming languages, which I don't.
That's the line Guido walks: trying to find just the right combination of
different-but-better and intuitive-for-most-people, and the aforementioned
items from the Zen of Python are a way of expressing that.

-Dave

[John Roth]

"David Eppstein" <ep******@ics.u ci.edu> wrote in message
news:ep******** *************** *****@news.serv ice.uci.edu...

In article <lc************ @gaffa.mit.edu> ,
Douglas Alan <ne****@mit.edu > wrote:

"Dave Brueck" <da**@pythonapo crypha.com> writes:

Part of the problem here is that just saying "only one way to do it" is a horrible misquote, and one that unfortunately misses IMO some of the most important parts of that "mantra":
Well, perhaps anything like "only one way to do it" should be removed
from the mantra altogether, since people keep misquoting it in order
to support their position of removing beautiful features like reduce()
from the language.

I think the more relevant parts of the zen are:
Readability counts.
Although practicality beats purity.

The argument is that reduce is usually harder to read than the loops it
replaces, and that practical examples of it other than sum are sparse
enough that it is not worth keeping it just for the sake of
functional-language purity.

IMO, this arguement is basically religious, that is, it is not based
on common sense. Apply, lambda, map, filter and reduce never constituted
a complete set of functional programming constructs, so trying to
make them so for the sake of the arguement is, basically, silly.

Apply was absorbed into the language core with a small change
in function call specifications. Good idea - it gets rid of a built-in
function.
Map and filter were (almost) obsoleted by list comprehensions and the zip
built-in function. Whether or not list comprehensions are clearer than map
and filter is debatable, but the only thing we lost in the transition was
map's
capability of processing lists of different lengths.

Sum is not an adequate replacement for reduce, regardless of the
performance benefits. Something similar to a list comprehension would
be. I don't, at this point, have a good syntax to suggest though.

A not so good example would be:

numbers = [1, 2, 3, 4]
result = [x: x + i for i in numbers]

The ":" signals that the result is a single object, not a list of
objects. The first list element is bound to that label, and then
the expression is evaluated for the rest of the elements of the list(s).

The problem with the syntax is the brackets, which suggest that the
result should be a list.

John Roth
--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science

[Bob Gailer]

I am glad to hear others rise to the "defense" of reduce(). I too am
reluctant to see it leave the language, as I'd have to rewrite some of my
code to accommodate the change.

The use of zip(seq[1:], [:-1]) to me is more obscure, and
memory/cpu-expensive in terms of creating 3 new lists.

Bob Gailer
bg*****@alum.rp i.edu
303 442 2625
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.538 / Virus Database: 333 - Release Date: 11/10/2003