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.

[Anton Vredegoor]

On 9 Nov 2003 22:40:57 GMT, bo**@oz.net (Bengt Richter) wrote:

[ackerman function generates very long integers]

Is there a fast formula for computing results, ignoring the representation problem?

This seems to be an easy way to generate them faster:

http://www.kosara.net/thoughts/ackermann.html

... back to the topic of this thread ...

From what I get of the main discussion (recursion vs iteration) it is
reasonable to not make a distinction based on the type of algorithm
but to only look at the order in which the nodes of the search space
are visited. It seems possible to turn recursive functions into
iterative ones by pushing and popping a stack of argument values.

This opens up possibilities of continuing from arbitrary positions of
the stack instead of just by pushing and popping ...

Anton

[David C. Fox]

Alex Martelli wrote:

P. S. I've seen a lot of talk about removing old features from Python,
or specifically old built-ins, because of bloat. Does this "bloat"
reduce performance, or does it refer to the extra burden on someone
learning the language or reading someone else's code?

A slightly larger memory footprint, and larger built-ins dictionaries,
can only reduce runtime performance very marginally. The "cognitive
burden" of having built-ins that "don't carry their weight", on the
other hand, is considered an issue *in Python*, because it doesn't fit
in with Python's general philosophy and worldview. Python is meant to
be a LEAN language (with a not-lean standard library of modules that
are specifically imported when needed); certain "legacy" features are
sub-optimal (and best removed, when the strict constraint of backwards
compatibility can be relaxed) because they interfere with that (and
built-ins are close enough to "the core language" that they _do_ need
to be weighed severely in terms of "how often will they be useful").

Thanks, that's what I was trying to understand.

David

[Georgy Pruss]

Thank you!
G-:

"Alex Martelli" <al***@aleax.it > wrote in message news:%R******** *********@news2 .tin.it...
| <skip>

[Francis Avila]

"Alex Martelli" <al***@aleax.it > wrote in message
news:Bs******** *************** @news2.tin.it.. .

Francis Avila wrote:

[a reduce() clone]

[a long and thorough critique]

*Sigh* My only objective was to combine functional/recursive/iterative
programming styles into an olive branch to extend to both parties of this
silly war.

But oh well. Like I said, I never found a use for reduce, but alas, I am a
ham-fisted programmer entirely lacking in subtlety and art....
--
Francis Avila

[Douglas Alan]

Alex Martelli <al***@aleax.it > writes:

Anybody who can claim (without a smilie) that "sum is redundant with
reduce" has clearly lost all touch with reality.
*All* touch? My girlfriend still feels real to me when I touch
her....
"sum" accounts for about 80-90% of the uses of reduce found on large
existing codebases,
I have *never* used sum() (or a reduce() that ammounts to sum()). And
I use reduce() fairly often, in more or less the way that I described.
and even more when only _good_ uses of reduce are considered. "sum"
is way faster than "reduce(operato r.add, ..." -- and the advantage
in speed *AND* simplicity
I don't care about speed all that much when using Python. If I did, I
probably wouldn't be using Python. And to me, "simple" means
providing a small number of orthogonal features that combine easily,
rather than a lot of special purpose features, that all have to be
learned, remembered, and documented separately. sum() is a
special-purpose feature, while reduce() is a very general feature that
is very easily adapted to a myriad of situations. So what if 80-90%
of the uses of reduce in your experience is to support sum()? That's
not my experience, and even if it were, if sum() is used a lot, then
10-20% of that is still a lot. max(), like sum() also has a built-in
reduce. So the current approach for the future of Python seems to be
to build reduce() into everything that might need it? I'd prefer to
see reduce() taken out of sum() and out of max() and then no one needs
to document or learn that sum() and max() duplicate the functionality
of reduce(). Just learn, remember, and document one thing, and you're
all set.
grows even more when one considers how
often that typical reduce is miscoded as "reduce(lam bda x, y: x+y,
..." or "reduce(int.__a dd__, ..." and the like.
People who do this, no doubt, are more interested in coding than
wading through a big manual to figure out to make use of Python's
idiosyncracitie s to get their code to run as fast as possible in this
one particular implementation of Python.

Such people are surely not going to want to wade through the manual to
find sum().
The complications of going to a higher-order function and learning about
module operator "pay off" in a SLOWDOWN compared to elementary code...!
All of 3.4% according to your calculations. I'm not losing any sleep
over it.

Learning about module operator is not a chore, since I'd want to know
how to access these operators anyway.

Higher order functions are not complicated -- they are beautiful and
elegant.
The "fancy" ways reduce is often coded slow things down further by about
two times. This is clearly unacceptable.
There's nothing fancy about reduce() -- it's taught in every CS 101
class!
And the right solution is, quite obviously: [alex@lancelot test]$ timeit.py -c 'sum(xrange(999 ))'
10000 loops, best of 3: 129 usec per loop
Why? Because it saves having to type "operator.add," ? Because it's a
bit faster? Who cares about either one of these things. Certainly
not I.
giving speed, simplicity, and code that is clean, high-level, concise, and
immediately obvious to any reader or maintainer.
reduce() is immediately obvious to anyone who has ever taken CS
101. sum() is going in the direction of Perl, where there's a separate
idiomatic feature for everything that anyone might ever want to do.

I like Python because it is a very simple, generic, easy-to-learn
programming language, where I didn't have to learn much of anything
anything new. It was just like all the other myriad of programming
languages I have programmed in, only less cluttered than most, and
"light-weight" in its implementation and accessibility.

I having nothing against learning new stuff, by the way, but when I
want to learn new stuff, I'm not particularly interested in the
idiosyncrasies of Python -- I'd spend my effort learning something a
bit more exotic, like OCaml, or Haskell, that might stretch my brain a
bit. Learning a bunch of idiosyncratic detail is just tedious. This
is one of the most important reasons that Perl sucks so badly.
The paladins of reduce don't help their case by posting reduce "use
cases" that are complicated and rarely optimal:

def longer(x, y):
if len(y) > len(x): return y
else: return x def longest(seq):
return reduce(longer, seq) print longest(("abc", "yumyum!", "hello", "goodbye", "?"))

There's nothing complicated about my example. It's the epitome of
clarity and elegance.
In 2.4, the much simpler expression:
list.sorted(seq , key=len)[-1]
is about 3 times faster on a typical long seq (seq=map(str, xrange(2000)).
There's nothing simpler about that (in fact, conceptually, it's much
more complex) and it's only faster because of Python implementation
details. In most languages, or an alternate implementation of Python,
sorting a list would typically be significantly slower than a linear
search on it.
We still don't have (in the current pre-alpha 2.4) the "one obvious way",
max(seq, key=len), because max & other functions haven't yet been upgraded
to take the optional parameter key= as lists' sort and sorted methods, but
I trust they will be.
More annoying bloat. Instead of pumping up max() with bloat, tell
people to use reduce(). It's already there and simple and elegant.
And if one doesn't care for the concision of these new idioms, the most
elementary programming is still best: [alex@lancelot test]$ timeit.py -c -s'xs=map(str,xr ange(2000))' -s'''

def longest(seq):
seq=iter(seq)
best = seq.next()
blen = len(best)
for item in seq:
ilen = len(item)
if ilen>blen:
best = item
blen = ilen
return best
''' 'longest(xs)' 1000 loops, best of 3: 980 usec per loop

That's supposed to be best? It would take me 100 times as long to
figure out that code.
Once again, reduce proves to be an "attractive nuisance":
With the emphasis on "attractive ". It results in easy-to-read, easy
to remember coding techniques.
Higher order programming, such as the "max(seq, key=len)" which I
hope will make it into 2.4, is of course way simpler, faster, and
more concise -- but the "neither fish nor fowl" level at which most
uses of reduce fall just doesn't cut it, IMHO.
Except for that I'd never use it because I'd never even know it was
there because I prefer to spend my time writing software than wading
through manuals.
And btw, if one wants concision rather than speed, even in 2.3, the
typical DSU-like idiom:
def longest(seq):
aux = [ (len(x), -i, x) for i, x in enumerate(seq) ]
return max(aux)[-1]
still handily beats the reduce-coded alternative (even though
having the len= parameter instead of explicit decoration will
of course make it even smoother, simpler, and faster, in 2.4).

The above is particularly ugly.

|>oug

[Robin Becker]

In article <vr************ @corp.supernews .com>, Francis Avila
<fr***********@ yahoo.com> writes

"Alex Martelli" <al***@aleax.it > wrote in message
news:Bs******* *************** *@news2.tin.it. ..

Francis Avila wrote:

[a reduce() clone]

[a long and thorough critique]

*Sigh* My only objective was to combine functional/recursive/iterative
programming styles into an olive branch to extend to both parties of this
silly war.

But oh well. Like I said, I never found a use for reduce, but alas, I am a
ham-fisted programmer entirely lacking in subtlety and art....
--
Francis Avila

This whole thread is reminiscent of vi vs emacs or an os war or similar.
It's a pity that people with a preferred style should be so dogmatic
that they want to remove language features to prevent others using them.

The whole 'only one way to do it' concept is almost certainly wrong.
There should be maximal freedom to express algorithms. As others have
stated min, max,... sum et al are useful specialisations , but because
they cover 99% of the space doesn't mean that reduce is redundant.
-Eliminate reducespeak and control the future-ly yrs-
Robin Becker

[Alex Martelli]

Robin Becker wrote:
...

This whole thread is reminiscent of vi vs emacs or an os war or similar.
It's a pity that people with a preferred style should be so dogmatic
that they want to remove language features to prevent others using them.
Python's essence is simplicity and uniformity. Having extra features
in the language and built-ins runs directly counter to that.

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 world is *chock full* of languages designed with the philosophy
of "the more, the merrier". Why can't you let us have just _*ONE*_
higher-level language designed with full appreciation for "the spirit
of C" (as per the C standard's Rationale) in its key principles:

"""
(c) Keep the language small and simple.
(d) Provide only one way to do an operation.
"""

Maybe "the spirit of C" is as wrong as you claim it is. Personally,
I _cherish_ it, and in Python I found a language that cherishes it
just as much, while working at a much higher semantic level and thus
affording me vastly higher productivity. I will not stand idly by,
and let you or anybody else attack its foundations and thus try to
destroy its key strengths, without a fight.

There should be maximal freedom to express algorithms. As others have

Want "maximal freedom to express algorithms"? You can choose among
a BAZILLION languages designed according to your philosophy -- even
sticking just to higher-level languages with dynamic typing and
generally infix/algoloid syntax, Perl is the obvious example, and if
you just can't stand its core syntax, in full respect of this
"maximal freedom" principle, you can of course change it, too -- see
http://www.csse.monash.edu.au/~damia...Perligata.html and
revel in that _truly_ maximal freedom. Or, for a language that's
somewhat in-between, but still philosophically accepts the "maximal
freedom" tenet for which you crave, try Ruby -- if I _did_ want such
freedom, then Ruby is what I'd most likely use.

But can't you let us have *ONE* language that's designed according
to the concept you consider "almost certainly wrong"?! Why do YOU
use this language, even while you condemn its foundation and try to
undermine them, rather than using any one of the myriad that already
DO follow your philosophy?!

Trying to make Python into (e.g.) a Ruby with slightly different
cosmetics and "fine points" is truly absurd: if you want Ruby, you
know where to find it. Let Python stay Python, and leave those of
us who find ourselves best served by its design principles in peace!
Alex

[Robin Becker]

In article <Os************ ******@news1.ti n.it>, Alex Martelli
<al***@aleax.it > writes

Robin Becker wrote:
...

This whole thread is reminiscent of vi vs emacs or an os war or similar.
It's a pity that people with a preferred style should be so dogmatic
that they want to remove language features to prevent others using them.
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.

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.
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.
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.
--
Robin Becker

[G.A.]

On Tue, 11 Nov 2003 11:39:20 +0000, Robin Becker
<ro***@jessikat .fsnet.co.uk> wrote:

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

To paraphrase a famous saying (at least in the context of US law), your
freedom ends where another person's maintenance headache begins.

Gary

[Douglas Alan]

Alex Martelli <al***@aleax.it > writes:

Robin Becker wrote:

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.

The mantra should be "small, clean, simple, powerful, general,
elegant". This, however, does not imply "only one way to do it",
because power and generality often provide for multiple "right" ways
to flourish. In fact, trying to enforce that there be only "one way
to do it", will make your language bigger, messier, more complicated,
less powerful, less general, and uglier, as misguided souls rush to
remove powerful and general tools like reduce() from the language, and
fill it up with special-purpose tools like sum() and max().

People have written entire articles on how to do functional
programming in Python:

http://www-106.ibm.com/developerwork...ry/l-prog.html

You would castrate Python so that this is not possible? Then you
would diminish Python, by making it a less general, less elegant
language, that has become unsuitable as a language for teaching CS101,
and only suitable for teaching How Alex Martelli Says You Should
Program 101.

|>oug