On Wed, Apr 11, 2018 at 6:55 PM, Paul Moore <p.f.mo...@gmail.com> wrote:
> On 11 April 2018 at 06:32, Chris Angelico <ros...@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.

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to