You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unpacking without parentheses is allowed since 3.9 #90881
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2022-02-22.18:31:20.414>created_at=<Date2022-02-11.18:10:30.648>labels= ['interpreter-core', '3.9', '3.10', '3.11']
title='Unpacking without parentheses is allowed since 3.9'updated_at=<Date2022-02-22.18:31:20.413>user='https://github.com/pablogsal'
Since this was already allowed in 3.9 and 3.10 stable relases, and since it is consistent with the RHS of an assignment (something = *a, *b); I'd lean towards keeping it (and maybe fixing the old parser's grammar to reflect that) and documenting this.
It's already been out for two releases, so there's user code out there relying on it. (In fact we found out about this because somebody complained that Black's parser couldn't handle this code.)
The syntax isn't obviously confusing and the meaning is clear.
It's not hard to parse; it was easy to adjust Black's parser to allow it.
Reacted by jmwielandt, Thomas Grainger, Vibhakar Solanki, Medardo Antonio Rodriguez, jh4mit, Jongwook Choi, Kolen Afix, Nikita Kurpas, Vishesh Panchal, Herman Beeksma and 1 more
What happened is that the new grammar using the PEG parser used the equivalent of starred_testlist instead of testlist for the iterable list of for statements.
The only extra thing allowed is starred elements, that are interpreted as if you are building a tuple without parentheses.
Activity
pablogsal commentedon Feb 11, 2022
Seems that this is allowed since the PEG parser rewrite:
but I cannot find anywhere were we discussed this. I am not sure if we should keep it or treat it as a bug and fix it.
isidentical commentedon Feb 11, 2022
Since this was already allowed in 3.9 and 3.10 stable relases, and since it is consistent with the RHS of an assignment (something = *a, *b); I'd lean towards keeping it (and maybe fixing the old parser's grammar to reflect that) and documenting this.
JelleZijlstra commentedon Feb 11, 2022
I'd lean towards keeping this syntax:
erlend-aasland commentedon Feb 11, 2022
+1 (what Jelle said)
gvanrossum commentedon Feb 11, 2022
Let's just document it for 3.11.
pablogsal commentedon Feb 11, 2022
Will prepare a PR
terryjreedy commentedon Feb 18, 2022
Allowing no parentheses is also consistent with the following:
for x in 1,2,3: print(x)
gvanrossum commentedon Feb 18, 2022
Adding jwilk back (a bpo interaction with browser form caching makes this happen frequently).
serhiy-storchaka commentedon Feb 22, 2022
What exactly was happened? What rule was changed? Can it cause other changes which allow ambiguous code or change semantic?
pablogsal commentedon Feb 22, 2022
What happened is that the new grammar using the PEG parser used the equivalent of starred_testlist instead of testlist for the iterable list of for statements.
The only extra thing allowed is starred elements, that are interpreted as if you are building a tuple without parentheses.
miss-islington commentedon Feb 22, 2022
New changeset 7fb94fd by Pablo Galindo Salgado in branch 'main':
bpo-46725: Document starred expressions in for statements (GH-31481)
7fb94fd