[Python-Dev] PEP 572: Assignment Expressions

Tim Peters tim.peters at gmail.com
Sat Apr 21 15:27:11 EDT 2018


[Tim]
>> I expected that, given that expressions "naturally nest", chained
>> targets could still be specified:
>>
>>     a := b := c:= 5
>>
>> but since they're all plain names there's no way to tell whether the
>> bindings occur "left to right" or "right to left" short of staring at
>> the generated code.

[Nick Coghlan <ncoghlan at gmail.com>]
> The fact class namespaces are ordered by default now allow us to
> demonstrate the order of multiple target assignments and tuple
> unpacking without staring at generated code:
>
> >>> class AssignmentOrder:
> ...     a = b = c = 0
> ...     d, e, f = range(3)
> ...
> >>> class ReversedAssignmentOrder:
> ...     c = b = a = 0
> ...     f, e, d = range(3)
> ...
> >>> [attr for attr in AssignmentOrder.__dict__ if not attr.startswith("_")]
> ['a', 'b', 'c', 'd', 'e', 'f']
> >>> [attr for attr in ReversedAssignmentOrder.__dict__ if not attr.startswith("_")]
> ['c', 'b', 'a', 'f', 'e', 'd']
>
> So that's a situation where "name = alias = value" could end up
> matching "alias := name := value"

Cool!  So this is really a killer-strong argument for getting rid of
classes - way overdue, too ;-)


> (Even in earlier versions, you can illustrate the same assignment
> ordering behaviour with the enum module, and there it makes even more
> of a difference, as it affects which name binding is considered the
> canonical name, and which are considered aliases).

So if binding expressions can be chained, they'll need to ape
"left-to-right" binding order.

Or they can't be allowed to chain to begin with.

Either way would be fine by me.


More information about the Python-Dev mailing list