[Python-ideas] PEP 572: Assignment Expressions (post #4)

Chris Angelico rosuav at gmail.com
Wed Apr 11 05:30:47 EDT 2018


On Wed, Apr 11, 2018 at 6:55 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 11 April 2018 at 06:32, Chris Angelico <rosuav at gmail.com> wrote:
>> The name ``prefix`` is thus searched for at global scope, ignoring the class
>> name. Under the proposed semantics, this name will be eagerly bound, being
>> approximately equivalent to::
>>
>>     class X:
>>         names = ["Fred", "Barney", "Joe"]
>>         prefix = "> "
>>         def <listcomp>(prefix=prefix):
>>             result = []
>>             for name in names:
>>                 result.append(prefix + name)
>>             return result
>>         prefixed_names = <listcomp>()
>
> Surely "names" would also be eagerly bound, for use in the "for" loop?

Yep, exactly. Have corrected the example, thanks.

>> This could be used to create ugly code!
>> ---------------------------------------
>>
>> So can anything else.  This is a tool, and it is up to the programmer to use it
>> where it makes sense, and not use it where superior constructs can be used.
>
> Related objection - when used to name subexpressions in a
> comprehension (one of the original motivating use cases for this
> proposal), this introduces an asymmetry which actually makes the
> comprehension harder to read. As a result, it's quite possible that
> people won't want to use assignment expressions in this case, and the
> use case of precalculating expensive but multiply used results in
> comprehensions will remain unanswered.
>
> I think the response here is basically the same as the above - if you
> don't like them, don't use them. But I do think the additional nuance
> of "we might not have solved the original motivating use case" is
> worth a specific response.

The PEP has kinda pivoted a bit since its inception, so I'm honestly
not sure what "original motivating use case" matters. :D I'm just
lumping all the use-cases together at the same priority now.

> Overall, I like this much better than the previous proposal. I'm now
> +1 on the semantic changes to comprehensions, and barely +0 on the
> assignment expression itself (I still don't think assignment
> expressions are worth it, and I worry about the confusion they may
> cause for beginners in particular).

Now that they have the same semantics as any other form of assignment,
they're a bit less useful in some cases, a bit more useful in others,
and a lot easier to explain. The most confusing part, honestly, is
"why do we have two ways to do assignment", which is why that is
specifically answered in the PEP.

ChrisA


More information about the Python-ideas mailing list