[Python-Dev] ',' precedence in documentation

Guido van Rossum guido at python.org
Sun Sep 14 22:00:14 CEST 2008


On Sun, Sep 14, 2008 at 12:47 PM, Fredrik Lundh <fredrik at pythonware.com> wrote:
> C. Titus Brown wrote:
>
>> over on the pygr list, we were recently discussing a mildly confusing
>> edit I made:
>>
>>   assert 'seq1' in self.db, self.db.keys()
>> This was interpreted by someone as being
>>
>>   assert 'seq1' in (self.db, self.db.keys())
>>
>> which is very different from the actual meaning,
>>
>>   assert ('seq1' in self.db), self.db.keys()
>>
>> where 'self.db.keys()' serves as the message to be printed out when the
>> assertion fails.  Apart from questions of why I was apparently out to
>> confuse people with this edit, the question of ',' precedence came up.
>> Looking at
>>
>>        http://docs.python.org/ref/summary.html
>>
>> there's no mention of ',' binding and tuple creation vs the other
>> operators.
>
> A bare "," is part of the "expression list" syntax; it's not an operator:
>
>    http://docs.python.org/ref/exprlists.html
>
> You have to look at the statement descriptions to find out whether a
> statement wants an expression or an expression list (e.g. "return" takes an
> expression list, while "assert" takes two expressions, not two expression
> lists).

Note that in any case, the 'in' operator binds more tightly than the
comma: e.g. f(x in y, z) means f((x in y), z). The only seeming
exception to this rule is the 'for' statement (and list comprehensions
and generator expressions) where 'in' is not an expression operator
but part of the statement syntax.

So if someone thought

  assert 'seq1' in self.db, self.db.keys()

meant

  assert 'seq1' in (self.db, self.db.keys())

they'd be in for a nasty surprise trying the same trick in an 'if'
statement, like this:

  if 'seq1' in self.db, self.db.keys(): ...

Fortunately that raises a syntax error. The really bad surprises come
from things like

  assert x in A, x in B

which I've seen assumed to mean

  assert (x in A) and (x in B)

in claimed analogy to the use of the comma in the print statement.

I think in general Python has erred on the side of having too many
different syntactical uses for commas. We killed a few in 3.0 with the
introduction of "except E as v" and the demotion of print to a
function call. Perhaps we should aim to kill "assert B, S" as well?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list