[Python-Dev] ',' precedence in documentation (original) (raw)

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