Python language spec

Tim Peters tim_one at email.msn.com
Sun Jan 2 21:43:26 EST 2000


[Nolan Darilek, by his own claim biting off more than he
 can chew <wink>]
> ...
> I'm confused by the expression_list definition, however. It
> reads:
>
> expression_list:      expression ("," expression)* [","]
>
> I understand the syntax of the definition, but I don't know
> what the syntax for an expression should be. Earlier rules
> define u_expr, a_expr, etc. but not a regular expression
> (I don't mean regexp, just a no-frills expression :). The
> only rule which defines 'expression' is:
>
> expression:     or_test | lambda_form
>
> which seems to imply that 'expression' is only a boolean
> result, which I'm guessing it isn't. :)
>
> [and various dead ends resulting from trying to talk himself
>  into believing the grammar doesn't mean what it says]

I don't have time to explain this in detail.  The short course is that, in
un-YACC-like fashion, Python's grammar makes operator precedence explicit in
the structure of the grammar.  The top level for expression is "or_test"
because the "or" operator has the lowest precedence.  When you look up
or_test, you'll find

or_test:        and_test | or_test "or" and_test

because the "and" operator has the next-lowest precedence.  Note that the
*structure* of the RHS forces all "and" expressions to be grouped together
before consuming an "or" (i.e., it forces "and" to "bind tighter" than
"or").  Then

and_test:       not_test | and_test "and" not_test

and on and on.  You'll eventually hit comparisons and arithemetic operators.
And, yes, a simple expression like "1+1" winds its way up the grammar
hierarchy all the way up to or_test.

Note that the official grammar lives in the file Grammar/Grammar (in the
source distribution); looking at that is a lot easier than trying to pick it
out of the Reference Manual.

> ... I don't completely understand why:
>
> expr: expr "*" expr { output }
> expr: expr "/" expr { output } ...
>
> wouldn't work?

Because you can't tell from those two rules whether "*" or "/" binds tighter
(they happen to have equal precedence, but throw in "+" too and the problem
will be more obvious).

You can rest assured that the grammar "works":  Grammar/Grammar is the input
to Python's own parser generator, and the output of the latter is what's
used to parse Python programs.

knowing-it-works-is-half-the-battle-ly y'rs  - tim






More information about the Python-list mailing list