Holger Krekel wrote (answering Raymond Hettinger):
...
Actually I think RH meant "bestscore, bestplayer = ..." here...
Although most people on python-dev and here seems to like this PEP I
think it generally decreases readability. The above constructs seem
heavy and difficult to parse and thus i am afraid that they interfere
with the perceived simplicity of Python's syntax.
Let's see: today, I could code:
sum([x*x for x in roots])
In 2.4, I will be able to code instead:
sum(x*x for x in roots)
with some performance benefits. Could you please explain how using
the lighter-weight simple parentheses rather than today's somewhat
goofy ([ ... ]) bracketing "generally decreases readability"...?
Similarly, today's:
bestscore, bestplayer = max([ (p.score, p.name) for p in players ])
I'll be able to code as a somewhat faster:
bestscore, bestplayer = max( (p.score, p.name) for p in players )
Again, I don't see how the proposed new construct is any more "heavy
and difficult to parse" than today's equivalent -- on the contrary,
it seems somewhat lighter and easier to parse, to me.
It may be a different issue (as you appear, from a later message, to
be particularly enamoured of Python's current 'fp' corner) to claim
that, say, yesteryear's (and still-usable):
reduce(operator.add, map(lambda x: x*x, roots))
"increases readability" compared to the proposed
sum(x*x for x in roots)
It boggles my mind to try thinking of the latter as "heavy and
difficult to parse" compared to the former, to be honest. And
when I'm thinking of "the sum of the squares of the roots", I
DO find the direct expression of this as sum(x*x for x in roots)
to be most immediate and obvious compared to spelling it out
as
total = 0
for x in roots:
total = total + x*x
which feels more like a series of detailed instructions on
how to implement that "sum of squares", while the "sum(x*x"...
DOES feel like the simplest way to say "sum of squares".
Sometimes it seems that introducing new syntax happens much easier
than improving or adding stdlib-modules.
What a weird optical illusion, hm? In Python 2.3 *NO* new syntax
was introduced (the EXISTING syntax for extended slices is now
usable on more types, but that's not "introducing" any NEW syntax
whatsoever), while HUNDREDS of changes were done that boil down
to "improving or adding standard library modules". So, it's
self-evidently obvious that the "happens much easier" perception
is pure illusion. In 2.4, _some_ syntax novelties are likely to
be allowed -- most PEPs under consideration are already in the
PEP repository or will be there shortly, of course (e.g., syntax
to support some variation of PEP 310, possibly closer to your
own interesting experiments that you reported back in February).
But once again there is absolutely no doubt that many more
changes will be to standard library modules than will "introduce
new syntax".
At least I hope that generator expressions will only be introduced
via a __future__ statement in Python 2.4 much like it happened with
'yield' and generators. Maybe the PEP should have an "implementation
plan" chapter mentioning such details?
I don't think __future__ has EVER been used for changes that do
not introduce backwards incompatibilities, nor do I see why that
excellent tradition should be broken for this PEP specifically.
Alex
