On Thu, 30 Nov 2017 at 05:01 David Cuthbert <dacut@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 <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



_______________________________________________
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/guido%40python.org