Re: [Python-Dev] ',' precedence in documentation]
----- Forwarded message from Guido van Rossum <guido@python.org> -----
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).
Exactly the point I was trying to make. As far as the user's concerned, an expression list x,y can itself be part of an expression; x in y is also an expression. Such expressions can be combined to form larger expressions, so it follows logically that you need to know which has precedence when *both* occur in an expression, e.g. whether x in y,z evaluates as (x in y),z or x in (y,z) The page that Fredrik sent you to (http://docs.python.org/ref/exprlists.html ) doesn't address that question. I still think the precedence table (http://docs.python.org/ref/summary.html ) should show that "in" has higher precedence than comma in an expression. Can anyone show us "where it is written" in the Python docs that "in" has higher precedence than comma, *and* why there is a good reason that this information should NOT be included in the precedence table? -- Chris Adding comma to the precedence table would also disambiguate expressions like: x and y,z x,y or z not x,y
On Sun, Sep 14, 2008 at 2:01 PM, Christopher Lee <leec@chem.ucla.edu> wrote:
----- Forwarded message from Guido van Rossum <guido@python.org> -----
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).
Exactly the point I was trying to make. As far as the user's concerned, an expression list x,y can itself be part of an expression; x in y is also an expression. Such expressions can be combined to form larger expressions, so it follows logically that you need to know which has precedence when *both* occur in an expression, e.g. whether x in y,z evaluates as (x in y),z or x in (y,z)
The page that Fredrik sent you to (http://docs.python.org/ref/exprlists.html) doesn't address that question. I still think the precedence table (http://docs.python.org/ref/summary.html) should show that "in" has higher precedence than comma in an expression.
Can anyone show us "where it is written" in the Python docs that "in" has higher precedence than comma, *and* why there is a good reason that this information should NOT be included in the precedence table?
-- Chris
Adding comma to the precedence table would also disambiguate expressions like: x and y,z x,y or z not x,y
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 . -- --Guido van Rossum (home page: http://www.python.org/~guido/)
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
On Mon, Sep 15, 2008 at 8:14 AM, Joel Bender <jjb5@cornell.edu> wrote:
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.
Um, the question I was answering specifically asked *where is this in the docs*.
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."
Good sleuthing. Since you have found an inconsistency, now all the docs are useless?
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.
But it is not -- it is the message passed to the exception constructor! -- --Guido van Rossum (home page: http://www.python.org/~guido/)
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
Joel Bender wrote:
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.
However, it doesn't take the same kind of argument as the "raise" statement, whereas this syntax might suggest that it does. -- Greg
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 <<Note: Python does not define comma as an operator, but instead just uses it as a separator in expression lists, function argument lists, and many other contexts. Note also that this disambiguates precedence: expression operators have higher precedence than the commas of an expression list. Thus the expression list "x and y, z" evaluates as "(x and y), z", not "x and (y, z)".>> 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 :-)...
Christopher> This is such a striking difference from C, where many of us Christopher> draw our default language assumptions, that it might be Christopher> worth highlighting in the Python docs, e.g. on the Christopher> expression list page. I added a question and answer to the programming FAQ. I agree it might be worthwhile to add a footnote to the operator precedence page though. Skip
Christopher Lee wrote:
precedence when *both* occur in an expression, e.g. whether
x in y,z
what part of "comma is not an operator" is so hard to understand? the above is not an expression. it's two expressions, separated by commas. the first expression stops at the comma. the second expression follows after the comma. commas can be a part of an expression only when they appear as part of a syntactic construct that allows commas (that is, parenthesized forms and displays, and the target list of a generator expression).
evaluates as
(x in y),z or x in (y,z)
The page that Fredrik sent you to (http://docs.python.org/ref/exprlists.html) doesn't address that question. I still think the precedence table (http://docs.python.org/ref/summary.html) should show that "in" has higher precedence than comma in an expression.
comma is not an operator.
Can anyone show us "where it is written" in the Python docs that "in" has higher precedence than comma, *and* why there is a good reason that this information should NOT be included in the precedence table?
because comma is not an operator? if we were to list everything that was not an operator in the precedence table, it would end up being very long and mostly pointless. </F>
Fredrik Lundh wrote:
Christopher Lee wrote:
Can anyone show us "where it is written" in the Python docs that "in" has higher precedence than comma, *and* why there is a good reason that this information should NOT be included in the precedence table?
because comma is not an operator? if we were to list everything that was not an operator in the precedence table, it would end up being very long and mostly pointless.
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. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
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 12:39:52 am Fredrik Lundh wrote:
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.
*puts up hand* 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".) Right or wrong, my mental model is that commas are the tuple operator, except in special places where it isn't and you have to use parentheses. Well, actually I know the model is wrong *now*, because I've read this thread, but until now I would have cheerfully described the comma as an operator. Judging by the number of hits on Goggle for 'Python "comma operator"', I'm not alone: over 4700 hits for comma operator versus 800 for comma separator. -- Steven
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
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? :-) -- Greg
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
On Tue, 16 Sep 2008 10:50:45 am 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? :-)
Of course I had. If somebody had asked me, I probably would have guessed that there was some sort of special case in the parser for function calls. I didn't say my mental model was a good model, but it was the only one I had. I have no doubt that there are others out there who are confused about the role of commas. -- Steven
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
On Mon, Sep 15, 2008 at 4:21 AM, <skip@pobox.com> wrote:
OTOH, comma is an operator in (I believe) all C-derived languages.
Even in C, the comma in argument lists is not the same as the comma operator! -- --Guido van Rossum (home page: http://www.python.org/~guido/)
"Guido" == Guido van Rossum <guido@python.org> 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
participants (8)
-
Christopher Lee -
Fredrik Lundh -
Greg Ewing -
Guido van Rossum -
Joel Bender -
Nick Coghlan -
skip＠pobox.com -
Steven D'Aprano