On 8/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On 8/3/07, Kurt B. Kaiser <[EMAIL PROTECTED]> wrote:
> > If the statistics on the usage of map() stay the same, 2/3 of the time
> > the current implementation will require code like
> >
> > foo = list(map(fcn, bar)).
>
> And the 2to3 tool should make this transformation (unless it can tell
> from context that it's unnecessary, e.g. in a for-loop, or in a call
> to list(), tuple() or sorted().
I hate to be pedantic, but it is not possible for 2to3 to tell, in general,
that it is safe to elide the list() because the result is used directly in a
for loop (for the usual arguments that use the Halting Problem as a trump
card). e.g.,
foo = map(f,seq)
for i in foo:
if g(i):
break
cannot be correctly transformed to (in Python 2.5 parlance):
foo = imap(f,seq)
for i in foo:
if g(i):
break
or equivalently:
for x in seq:
if g(f(x)):
break
when f has side-effects, since:
1. the loop need not evaluate the entire sequence, resulting in f(i) being
called for some prefix of seq
2. g(i) may depend on the side-effects of f not yet determined
Given that Python revels in being a non-pure functional language, we can
poke fun of examples like:
map(db.commit, transactions)
but we need to recognize that the semantics are very specific, like:
map(db.commit_phase2, map(db.commit_phase1, transactions))
that performs all phase 1 commits before any phase 2 commits.
More so, the former idiom is much more sensible when 'commit' returns a
meaningful return value that must be stored. Would we blink too much at:
results = []
for tx in transactions:
results.append(db.commit(tx))
except to consider rewriting in 'modern' syntax as a list comprehension:
results = [ db.commit(tx) for tx in transactions ]
I'm all for 2to3 being dumb. Dumb but correct. It should always put list()
around all uses of map(), filter(), dict.keys(), etc to maintain the exact
behavior from 2.6. Let the author of the code optimize away the extra work
if/when they feel comfortable doing so. After all, it is their
job/reputation/life on the line, not ours.
~Kevin
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
