[Python-Dev] Python 3.0 grammar ambiguous? (original) (raw)

Fabio Zadrozny fabiofz at gmail.com
Sun Mar 8 23:58:06 CET 2009

To be honest I wasn't aware of this ambiguity. It seems that whoever wrote the patch for argument unpacking (a, b, *c = ...) got "lucky" with an ambiguous grammar. This surprises me, because IIRC usually pgen doesn't like ambiguities. Other parser generators usually have some way to deal with ambiguous grammars, but they also usually have features that make it unnecessary to use the exact same grammar as pgen -- for example, most parser generators are able to backtrack or look ahead more than one token, so that they can distinguish between "a = b" and "a" once the '=' token is seen, rather than having to commit to parse an expression first.

JavaCC can actually do that, but in the current construct, the ambiguity is not dependent on a lookahead, because both '*' test and star_expr will match it equally well -- because they're actually the same thing grammar-wise (so, there's no way to disambiguate without a semantic handling later on)

After taking a 2nd look, I think that probably the best solution would be creating a new testlist to be used from the expr_stmt -- something like testlist_start_expr.

E.g.:

testlist: test (',' test)* [','] testlist_star_expr: [test | star_expr] (',' [test | star_expr])* [',']

And also, star_expr could probably be just '*' NAME (to make it faster to match -- or could it match something else?)

Note that I still haven't tested this -- I'll have time to do it tomorrow on my JavaCC grammar (so, I can give you a better feedback if this actually works).

Regards,

Fabio

More information about the Python-Dev mailing list