[Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Nick Coghlan]

On 26 April 2018 at 15:38, Chris Angelico <rosuav at gmail.com> wrote:
> On Thu, Apr 26, 2018 at 3:34 PM, Steven D'Aprano <steve at pearwood.info> wrote:
>> Can you give an example of a Python expression, involving PEP 572
>> binding-expressions, that is not a tree but a more general DAG or that
>> contains cycles?
>
> A DAG is a directed *acyclic* graph, so it still can't contain cycles.
> But I have no idea what kind of expression isn't a tree as a
> consequence of having an assignment in it.

At a parsing level, the expression remains a tree, it's just that one
of the nodes is a name lookup. At a logical level though, binding
expressions do indeed mean that expressions involving binding
expressions are at least arguably better modelled with a DAG rather
than as a tree the way they are now:

    # The arithmetic expression is a tree including two nodes that
look up "c". The DAG is only needed at a statement level.
    c = expr()
    a*c + b*c

    # Whereas this backref to "c" pulls the DAG down to the expression level
    a*(c := expr()) + b*c

Historically, that kind of order-of-evaluation dependence in Python
has only been a problem for functions with side effects, so the folks
asking that this be seen as a major complexity increase for expression
level semantics have an entirely valid point. The PEP aims to address
that point by saying "Don't use binding expressions when the order of
evaluation would be ambiguous", but that's as a response to a valid
concern, not a dismissal of it.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia