On Thu, 30 Nov 2017 at 05:01 David Cuthbert <da...@kanga.org> wrote: > 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? >
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. -Brett > > Dave > > > On 11/25/17, 9:03 PM, Nick Coghlan wrote: > > On 26 November 2017 at 09:22, Terry Reedy <tjre...@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 | ncogh...@gmail.com | Brisbane, Australia > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
