On 18 April 2018 at 10:20, Guido van Rossum <guido at python.org> wrote:
[Tim Peters wrote]
>> 2. Back off and limit assignment expressions to what appears to be the
>> overwhelmingly most common case motivated by looking at real code (as
>> opposed to constructing examples to illustrate pitfalls &
>> obscurities):
>>
>> identifier ":=" expression
>
>
> I haven't had the time to follow this thread in detail; fortunately I don't
> have to because of Tim's excellent channeling.
>
> I am fine with this, it certainly seems the easiest to implement, with the
> fewest corner cases, and the easiest restriction to explain.
>
> (I was thinking there would be a use case for basic tuple unpacking, like
> seen a lot in for-loop, but the only examples I tried to come up with were
> pretty sub-optimal, so I don't worry about that any more.)
In the other direction I was thinking about the question "Then why do
I think tuple unpacking is OK in comprehensions?", and realised that
it's because in that situation there are keywords as delimiters on
both sides (i.e. "... for name [, name]* in ..."), so it's harder for
the unpacking operation to get confused with other uses of commas as
separators. Similarly, in regular assignments, the unpacking target is
always either between two "=" or else from the start of the line to
the first "=".
By contrast, for assignment expressions, the only potential explicit
opening delimiter is "(", and that's also the case for tuple literals.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4