> 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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
