[Python-ideas] Assignments in list/generator expressions

Guido van Rossum guido at python.org
Mon Apr 11 01:06:01 CEST 2011


On Sun, Apr 10, 2011 at 11:31 AM, Eugene Toder <eltoder at gmail.com> wrote:
>> We'll have to disagree then.  I think 'for name in [expr]' is a whole
>> lot more readable than 'with name = expr'.  Indeed, my recent
>> experience in code reading had shown, I thought, that a good number of
>> people are using the with statement

Eugene, I'm pretty sure you didn't write that, but as I'm not
following this megathread in real time I don't know who did. Can you
please be so kind to leave attributions in? (I'm glad you snip stuff
you don't need, but the attributions are essential.)

> If I was not clear: I used 'with' keyword for demonstration purposes
> only, to show what the syntax *might* look like. I do not suggest to
> reuse 'with' (even though python has a history keywords reuse, e.g.
> 'else'), it's just a placeholder.

It was not clear.

>> While naming the iteration variables is a fundamental part of writing
>> comprehensions, naming other subexpressions is not, so it doesn't make
>> sense to provide comprehension specific syntax for it.
>
> Well, apparently designers of Haskell, Scala, F# and Clojure decided
> that it does make sense to provide a comprehension specific syntax for
> naming subexpressions in comprehensions.

If the designers of Haskell, Scala, F# and Clojure jumped off a cliff,
would you jump too? :-)

Those languages are all considerably more "functional" in nature than
Python will ever be.

It's hard to express Python's design principles exactly, but
"following other languages" has never been high on the list. We do
borrow good ideas, but tend to reinterpret them in the context of
Python's existing semantics, syntax and constraints. We also place a
high value on growing the language very slowly and carefully; too many
shiny new features are more likely to distract than to help, even if
each one individually is a great idea. And we have a history of stuff
we do and don't like, which may not always be rational, but which has
served us well up to here. If you don't like it, you can always write
one of those other languages...

(That's not to say that I am vetoing a specific proposal. But the bar
is high, and inventing a "Pythonic" syntax is a prerequisite. So is a
good story with a set of examples explaining why the new feature adds
something you cannot easily do today.)

-- 
--Guido van Rossum (python.org/~guido)



More information about the Python-ideas mailing list