It could also be postponed simply by saying assignment expressions follow
the same semantics as other bindings in comprehensions... which are subject
to change pending PEP XXXX (i.e. some different number).

On the other hand, I am one who doesn't really care about assignment
expressions in comprehensions and only see the real benefit for 'if' and
'while' statements. I'm sure if it's added, I'll wind up using them in
comprehensions, but I've been perfectly happy with this for years:

stuff = [[y, x/y] for x in range(5) for y in [f(x)]]

There's nothing quite analogous in current Python for:

while (command := input("> ")) != "quit":
    print("You entered:", command)

On Sat, Apr 21, 2018, 11:57 AM Nick Coghlan <> wrote:

> On 22 April 2018 at 01:44, David Mertz <> wrote:
> > It feels very strange that the PEP tries to do two almost entirely
> unrelated
> > things. Assignment expressions are one thing, with merits and demerits
> > discussed at length.
> >
> > But "fixing" comprehension scoping is pretty much completely orthogonal.
> > Sure, it might be a good idea. And yes there are interactions between the
> > behaviors. However, trying to shoehorn the one issue into a PEP on a
> > different topic makes all of it harder to accept.
> >
> > The "broken" scoping in some slightly strange edge cases can and has been
> > shown in lots of examples that don't use assignment expressions. Whether
> or
> > not that should be changed needn't be linked to the real purpose of this
> > PEP.
> The reason it's covered in the PEP is because the PEP doesn't want to
> lock in the current "binds the name in the surrounding scope"
> semantics when assignment expressions are used in the outermost
> iterable in a comprehension.
> However, resolving that question *could* be postponed more simply by
> making that a SyntaxError, rather than trying to move the expression
> evaluation inside the implicitly nested scope.
> Cheers,
> Nick.
> --
> Nick Coghlan   |   |   Brisbane, Australia
Python-Dev mailing list

Reply via email to