[Python-Dev] PEP 492 vs. PEP 3152, new round (original) (raw)

Greg Ewing greg.ewing at canterbury.ac.nz
Thu Apr 30 10:56:10 CEST 2015

Nathaniel Smith wrote:

Even if we put aside our trained intuitions about arithmetic, I think it's correct to say that the way unary minus is parsed is: everything to the right of it that has a tighter precedence gets collected up and parsed as an expression, and then it takes that expression as its argument.

Tighter or equal, actually: '--a' is allowed.

This explains why Yury's syntax disallows 'await -f'. The 'await' operator requires something after it, but there's nothing between it and the following '-', which binds less tightly.

So it's understandable, but you have to think a bit harder.

Why do we have to think harder? I suspect it's because the notion of precedence is normally introduced to resolve ambiguities. Knowing that infix '*' has higher precedence than infix '+' tells us that 'a + b * c' is parsed as 'a + (b * c)' and not '(a + b) * c'.

Similarly, knowing that infix '.' has higher precedence than prefix '-' tells us that '-a.b' is parsed as '-(a.b)' rather than '(-a).b'.

However, giving prefix 'await' higher precedence than prefix '-' doesn't serve to resolve any ambiguity. '- await f' is parsed as '-(await f)' either way, and 'await f + g' is parsed as '(await f) + g' either way.

So when we see 'await -f', we think we already know what it means. There is only one possible order for the operations, so it doesn't look as though precedence comes into it at all, and we don't consider it when judging whether it's a valid expression.

What's the conclusion from all this? I think it's that using precedence purely to disallow certain constructs, rather than to resolve ambiguities, leads to a grammar with less-than-intuitive characteristics.

-- Greg

More information about the Python-Dev mailing list