[Python-Dev] Python 3.0 grammar ambiguous?

[Fabio Zadrozny]

>> 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).
>

Ok, I've created a bug for that at: http://bugs.python.org/issue5460
and commented on a solution (and just to note, star_expr could match
b, *a.a = [1,2,3], so, it cannot be changed for NAME)

The solution is working for me, and it should be straightforward to
apply it to Python.

Regards,

Fabio