+1 on extracting the big win for "if" and "while" (the regex case is
wonderul). It would be see as an "extended if/while" rather than a general
statement assignation.
+1 on list comprehensions, even if I prefer the
[(y, x/y) with y = f(x) for x in range(5)] or [(y, x/y) for x in range(5)
with y = f(x)] syntax (more close to "for y in [ f(x) ]".
Le 2 mars 2018 15:54, "Rhodri James" <rho...@kynesim.co.uk> a écrit :
On 02/03/18 11:43, Chris Angelico wrote:
> After dozens of posts and a wide variety of useful opinions and
> concerns being raised, here is the newest version of PEP 572 for your
> debating pleasure.
>
I haven't said this yet, so thanks Chris for putting this all together.
Even if the result is a rejected PEP, at least we have everything in one
place.
[snip]
# Compound statements usually enclose everything...
> if (re.match(...) as m):
> print(m.groups(0))
> print(m) # NameError
>
This (and the equivalent in while loops) is the big win in the PEP, in my
opinion. The number of ugly loops I've had to write in Python because I
can't write "while (something_to_do() as event):"... +1 on this.
# Using a statement-local name
> stuff = [[(f(x) as y), x/y] for x in range(5)]
>
As Paul said, the asymmetry of this bothers me a lot. It doesn't read
naturally to me. -1 on this.
1. What happens if the name has already been used? ``(x, (1 as x), x)``
> Currently, prior usage functions as if the named expression did not
> exist (following the usual lookup rules); the new name binding will
> shadow the other name from the point where it is evaluated until the
> end of the statement. Is this acceptable? Should it raise a syntax
> error or warning?
>
I wouldn't worry too much about this case. Anyone gratuitously reusing
names like that deserves all that will be coming to them.
Alternative proposals
> =====================
>
> 3. ``with... as``::
>
> stuff = [(y, x/y) with f(x) as y for x in range(5)]
>
> As per option 2, but using ``as`` in place of the equals sign. Aligns
> syntactically with other uses of ``as`` for name binding, but a simple
> transformation to for-loop longhand would create drastically different
> semantics; the meaning of ``with`` inside a comprehension would be
> completely different from the meaning as a stand-alone statement.
>
Honestly I prefer this syntax for comprehensions. It doesn't read
perfectly but it's good enough (though I am a mathematician by original
training, so set notation works for me anyway), and the syntax is clear and
limited.
I'm not sure the case for fully general statement-local variables has been
made.
So, counter-proposal(s):
1. Allow "(f() as a)" in the conditions of "if" and "while" statements,
after some arguing as to whether "a" is a special snowflake or just a
normal local variable.
2. Add a "with" clause to comprehensions to make comprehension-local
variables (presumably the same class of thing as the iteration variables).
--
Rhodri James *-* Kynesim Ltd
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
