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 <tjreedy@udel.edu> 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 | ncoghlan@gmail.com | Brisbane, Australia