Allow unparenthesized walrus in set literals, set comprehensions and indexes#162
Conversation
|
I believe it looks fine, thanks @gousaiyang! @davidhalter can you check this out? "The ambiguity arises in" |
|
Sorry for the delay (was awaiting my firstborn :)), but thanks for the change! I think this is definitely fine, but I will check why this causes ambiguities. IMO we will have to find a (PEG) solution for the parser anyway during the next year, so this grammar change is not a problem anyway. |
🚀 Congratulations! |
|
I just tried to check why the ambiguity problem arises: The problem in the latter example is that for all the first tokens (e.g. for a So this is definitely a limitation of our current parser. |
|
Also released 0.8.1 with this. |
Implementation stolen from PR davidhalter/parso#162. Thanks parso! I could add support for these newer syntactical constructs in the target version detection logic, but until I get diff-shades up and running I don't feel very comfortable adding the code.
Implementation stolen from PR davidhalter/parso#162. Thanks parso! I could add support for these newer syntactical constructs in the target version detection logic, but until I get diff-shades up and running I don't feel very comfortable adding the code.
This incorporates two recent changes in CPython upstream:
{x := 1, 2, 3},{x4 := x ** 5 for x in range(7)}.a[b:=0],a[b:=0, c:=0].As for the code change, I cannot directly use
namedexpr_testindictorsetmakerandsubscriptbecause that will produce ambiguous rules.