<div dir="ltr">I'd be wary of going too far here. The parser (which uses a different representation for the grammar) may not support all of these -- in particular I would guess that the syntax for subscriptions is actually more complicated than shown, because of slices. Do you allow a[x:y, *rest]?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 30, 2017 at 10:27 AM, Brett Cannon <span dir="ltr"><<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span class=""><div dir="ltr">On Thu, 30 Nov 2017 at 05:01 David Cuthbert <<a href="mailto:dacut@kanga.org" target="_blank">dacut@kanga.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Henk-Jaap noted that the grammar section of the language ref for yield and return should also be updated from expression_list to starred_list with this change. As noted elsewhere, this isn't in-sync with the Grammar file (intentionally, if I understand correctly).<br>
<br>
I took a look, and I believe that every instance of expression_list (which doesn't allow the unparenthesized tuple unpacking) should be changed to starred_list. Which might really mean that starred_list should have never existed, and the changes should have been put into expression_list in the first place (though I understand the desire to be conservative with syntax changes).<br>
<br>
Here are the places where expression_list is still allowed (after fixing return and yield):<br>
<br>
subscription ::= primary "[" expression_list "]"<br>
augmented_assignment_stmt ::= augtarget augop (expression_list | yield_expression)<br>
for_stmt ::= "for" target_list "in" expression_list ":" suite<br>
["else" ":" suite]<br>
<br>
In other words, the following all produce SyntaxErrors today (and enclosing them in parentheses avoids this):<br>
a[1, *rest]<br>
a += 1, *rest # and other augops: -= *= /= etc.<br>
for i in 1, *rest:<br>
<br>
My hunch is these cases should also be fixed to be consistent. While I can't see myself using something like "a += 1, *rest" in the immediate future, it seems weird to be inconsistent in these cases (and reinforces the oft-mistaken assumption, from Terry's earlier reply, that tuples are defined by parentheses instead of commas).<br>
<br>
Any reason I shouldn't dig in and fix this while I'm here?<br></blockquote><div><br></div></span><div>It's really a question of ramifications. Do we want every place where parentheses tuples are required to allow for the non-paren version? If there was a way to get an exhaustive list of examples showing what would change in those instances then we could make a judgement call as to whether this change is desired.</div><div><br></div><div>-Brett<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br>
Dave<br>
<br>
<br>
On 11/25/17, 9:03 PM, Nick Coghlan wrote:<br>
<br>
On 26 November 2017 at 09:22, Terry Reedy <<a href="mailto:tjreedy@udel.edu" target="_blank">tjreedy@udel.edu</a>> wrote:<br>
> Since return and yield are often the first half of a cross-namespace<br>
> assignment, requiring the () is a bit surprising. Perhaps someone else has<br>
> a good reason for the difference.<br>
<br>
These kinds of discrepancies tend to arise because there are a few<br>
different grammar nodes for "comma separated sequence of expressions",<br>
which makes it possible to miss some when enhancing the tuple syntax.<br>
<br>
Refactoring the grammar to eliminate the duplication isn't especially<br>
easy, and we don't change the syntax all that often, so it makes<br>
sense to treat cases like this one as bugs in the implementation of<br>
the original syntax change (except that the "don't change the Grammar<br>
in maintenance releases" guideline means they still need to be handled<br>
as new features when it comes to fixing them).<br>
<br>
Cheers,<br>
Nick.<br>
<br>
P.S. That said, I do wonder if it might be feasible to write a<br>
"Grammar consistency check" test that ensured the known duplicate<br>
nodes at least have consistent definitions, such that missing one in a<br>
syntax update will cause an automated test failure. Unfortunately, the<br>
nodes typically haven't been combined because they have some<br>
*intentional* differences in exactly what they allow, so I also<br>
suspect that this is easier said than done.<br>
<br>
--<br>
Nick Coghlan | <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br></div></div>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/brett%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>brett%40python.org</a><br>
</blockquote></div></div>
<br>______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>guido%40python.org</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>