Guido van Rossum wrote:

...the syntax for "expression" doesn't allow a comma unless it's inside parentheses.

Perhaps a source of confusion might be that comma seems to act like a 'tuple join operator' when it is not inside parentheses. >>> x = 1, 2 >>> x (1, 2) And there is at least one point in the documentation where the comma is described as an operator: http://docs.python.org/ref/parenthesized.html "Note that tuples are not formed by the parentheses, but rather by use of the comma operator." As for the assert syntax, I would reuse the 'raise' keyword rather than 'else': assert_stmt ::= "assert" <expression> [ "raise" <expression> ] Which emphasizes that the expression is raised as an exception. Joel

Good sleuthing. Since you have found an inconsistency, now all the docs are useless?

LOL! Hardly! I only found one inconsistent page, and it happens to be one that I found a little hard to understand while I was learning the language. In ALGOL it is used as part of the statement, like: FOR I := 1, 5 STEP 2 UNTIL 9, 12 WHILE (X < 5) DO ... So I'm quite happy with it being an expression separator. I would re-write that part of the grammar to have a tuple_display like list_display, but it's not worth the effort.

But it is not -- it is the message passed to the exception constructor!

I apologize, oversimplified the statement. I wanted to express that it's not just passed as a parameter to the exception constructor, but the fact that the exception that that is constructed is also raised in some circumstances. I didn't mean to imply that the expression itself was raised. IMHO, the keyword "else" wasn't strong enough. Joel

On Sep 14, 2008, at 9:18 PM, Guido van Rossum wrote:

You don't seem to understand how to read syntax tables. The assert syntax is given as "assert expression , expression" and the syntax for "expression" doesn't allow a comma unless it's inside parentheses. That is all you need here, and that is what Fredrik pointed out. The precedence list only applies to expressions, not to other constructs like statements. (You might note that it also doesn't list the precedence of 'assert'.) The place to reference is http://docs.python.org/ref/assert.html .

Thanks. This is such a striking difference from C, where many of us draw our default language assumptions, that it might be worth highlighting in the Python docs, e.g. on the expression list page. Maybe something like <> Highlighting this would stop people with C backgrounds from assuming that comma is an operator, like I did. Analyzing the full syntax table would obviously sort this out, but a lot of people just read the docs (like I did :-)...

Nick Coghlan wrote:

While it may not make sense to list it in the table itself, having a note on that page that comma is NOT an operator (unlike C), and hence only permitted between expressions as part of another statement or expressions that permits it may not be a bad idea.

better include "=" and augmented assignments as well. on the other hand, we're talking about a single instance of a "someone" here -- it's not like there's any sign that the comma issue is something that lots of someones are confused about. (...and given that the precedence table has been broken for over a decade (see http://bugs.python.org/issue3558) due to a bug in the Latex-to-HTML renderer, one might wonder if anyone gets that far into the language reference at all...) </F>

On Tue, 16 Sep 2008 08:39:42 am Steven D'Aprano wrote:

I was confused about the role of commas, and totally gobsmacked when I discovered that commas make tuples everywhere except when following an except statement. (At least that's how I interpreted what I was seeing with "try...except A, B, C, e".)

Oops. Except of course the above is a syntax error. I meant: try...except (A, B, C), e -- Steven

Greg Ewing wrote:

Steven D'Aprano wrote:

...

I was confused about the role of commas, and totally gobsmacked when I discovered that commas make tuples everywhere except when following an except statement.

Um... you've never written a function call with more than one argument before? :-)

The existence of *args syntax makes that one a little blurry - there's often a hidden tuple of arguments involved, and it is still a case of "multiple expressions separated by commas". The special handling for varargs and varkwds expansion and keyword arguments are marked within the expressions with their own special syntax. Similarly, even though there is no actual tuple created in list, dict and set displays, function parameter lists and unpacking to multiple targets in an assignment statement, the usages share the characteristic that the things being separated are by and large equivalent. So to answer my own question from earlier in the thread, except clauses and assert statements are special because they are the only places where the expressions to the left and right of the comma relate to completely different concepts. We're fixing except clauses by replacing that comma with an 'as', but assert statements are still a bit odd. And to suggest another colour for the bikeshed, what if we just made "assert" a normal builtin, and required people to compile them out explicitly in optimised code via: if __debug__: assert(whatever, msg="whatever broke!") A source code transform (ala 2to3) could easily translate the old assert statements to the above. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

Fredrik> if we were to list everything that was not an operator in the Fredrik> precedence table, it would end up being very long and mostly Fredrik> pointless. OTOH, comma is an operator in (I believe) all C-derived languages. That's probably what throws people. It might be worth a short note: on the operator precedence page to point out that comma isn't an operator in Python. Skip

...

...

...

...

"Guido" == Guido van Rossum writes:

>> OTOH, comma is an operator in (I believe) all C-derived languages. Guido> Even in C, the comma in argument lists is not the same as the Guido> comma operator! True enough, further adding to peoples' confusion. If no change to the docs (in the form of a footnote?) is forthcoming, perhaps we should add a question to the programming FAQ. Skip