[Python-ideas] PEP 505 (None coalescing operators) thoughts

[Random832]

On Mon, Sep 28, 2015, at 15:47, Andrew Barnert via Python-ideas wrote:
> spam?.eggs.cheese becomes this pseudo-AST (I've skipped the loads and
> maybe some other stuff):
> 
>     Expr(
>         value=Attribute(
>             value=Attribute(
>                 value=Name(id='spam'), attr='eggs', uptalk=True),
>             attr='cheese', uptalk=False))

> … which is then compiled as this pseudo-bytecode:
> 
>     LOAD_NAME 'spam'
>     DUP_TOP
>     POP_JUMP_IF_NONE :label
>     LOAD_ATTR 'eggs'
>     LOAD_ATTR 'cheese'
>     :label

To put this in more concrete terms... What pseudo-AST does
(spam?.eggs).cheese end up as, if the notion that uptalk must not escape
parentheses is accepted?

The pseudo-bytecode is obvious:
LOAD_NAME 'spam'
JUMP_IF_NONE :label
LOAD_ATTR 'eggs'
:label
LOAD_ATTR 'cheese'

[If we're going to define a new opcode, might as well be one that
doesn't require a dup]

The AST, though, not so much. spam.eggs.cheese and (spam.eggs).cheese
are identical:

Expr(Attribute(Attribute(Name('spam'), 'eggs'), 'cheese'))

And you gave this for the non-parenthesized spam?.eggs.cheese
Expr(Attribute(Attribute(Name('spam'), 'eggs', True), 'cheese', False))

> I suppose the reference documentation wording is also important here, to
> explain that an uptalked attributeref or subscription short-circuits the
> whole primary.

Primary's not the right term here, because a parenthesized expression is
also a primary. And so is the first three (first two, first four) terms
of a five-dot expression. In the grammar the thing we want is called
atom_expr. Why *is* the BNF in the syntax documentation different from
the BNF in the grammar anyway?