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).
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).
Here are the places where expression_list is still allowed (after fixing return
and yield):
subscription ::= primary "[" expression_list "]"
augmented_assignment_stmt ::= augtarget augop (expression_list |
yield_expression)
for_stmt ::= "for" target_list "in" expression_list ":" suite
["else" ":" suite]
In other words, the following all produce SyntaxErrors today (and enclosing
them in parentheses avoids this):
a[1, *rest]
a += 1, *rest # and other augops: -= *= /= etc.
for i in 1, *rest:
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).
Any reason I shouldn't dig in and fix this while I'm here?
Dave
On 11/25/17, 9:03 PM, Nick Coghlan wrote:
On 26 November 2017 at 09:22, Terry Reedy <[email protected]> wrote:
> Since return and yield are often the first half of a cross-namespace
> assignment, requiring the () is a bit surprising. Perhaps someone else
has
> a good reason for the difference.
These kinds of discrepancies tend to arise because there are a few
different grammar nodes for "comma separated sequence of expressions",
which makes it possible to miss some when enhancing the tuple syntax.
Refactoring the grammar to eliminate the duplication isn't especially
easy, and we don't change the syntax all that often, so it makes
sense to treat cases like this one as bugs in the implementation of
the original syntax change (except that the "don't change the Grammar
in maintenance releases" guideline means they still need to be handled
as new features when it comes to fixing them).
Cheers,
Nick.
P.S. That said, I do wonder if it might be feasible to write a
"Grammar consistency check" test that ensured the known duplicate
nodes at least have consistent definitions, such that missing one in a
syntax update will cause an automated test failure. Unfortunately, the
nodes typically haven't been combined because they have some
*intentional* differences in exactly what they allow, so I also
suspect that this is easier said than done.
--
Nick Coghlan | [email protected] | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
