Thanks 2QdxY4RzWzUUiLuE for your thoughtful response. I shouldn't have used the word "expression" since it was going to be taken as a Python term. Let me clarify the issue. An optional starred expression (denoted "[starred_expression]" in the specification of the syntax) is a natural generalization of an expression list (which is not necessarily an expression in the Python sense) in the sense that use of the latter as a special case of the former will lead to intuitively expected results at all places where the former is allowed. The issue is these two things seem to be treated unnecessarily differently. Namely, the syntax requires an expression list at some places (not even optionally), but does not allow an optional starred expression at the same places. In such a place, one must turn an optional starred expression into an expression (in the Python sense) by putting parentheses around it while parentheses around an expression list are optional. This difference in treatment seemed unintuitive to me at least inside brackets. This means non-experts like me may need to take extra care to stay safe under possibility of confusion at those places. Must most non-experts be happy with this in your assessment? A solution would be simply not to exclude optional starred expressions where an expression list is required now (since it may be too late now to require a single expression at those places if that could be better). Best regards, Takuo

Dear Steve, Thank you for your thoughts. To be precise, the sequence of letters "*(1,2)" is not actually a "starred expression" in the sense of the Python Language, but e.g., "*(1,2), " is. (A comma is trailing.) Please check the definitions here: https://docs.python.org/3/reference/expressions.html#expression-lists For instance, "(*(1,2) )" raises SyntaxError. Now, is "1,2," more boxed up than "*(1,2)," is? The *current* rule surely says the former is a tuple at some places and the latter is not, but otherwise, I don't see any parenthesis nor bracket around "1,2,". May more parentheses than brackets visible there? I see commas in both, so that's not the difference. Is there no way "*(1,2)," could equally be boxed up at exactly the same places where "1,2," can? Importantly, what problem may be caused by this in practice, or from what problem does SyntaxError currently raised there save us? For instance, if someone writes "s[*(1,2),]" in fact wanting "s[ [*(1,2),] ]" but forgets to box up "*(1,2),", then the same thing can happen for "s[ [1,2,] ]" (i.e., it can be mistyped as "s[1,2,]" but without SyntaxError this time). It would at least be consistent if we got SyntaxError in both cases (namely, the syntax allowed only a single Python expression here), but if we don't want SyntaxError in the latter case, how may we want it in the former case? By the way, please note I wish "*(1,2)," to be treated like "1,2," only where the current syntax expects an expression list. Elsewhere, I don't mind it if starred expressions remain treated as unboxed or whatever. Best regards, Takuo

Matsuoka Takuo writes:

I don't see any parenthesis nor bracket around "1,2,".

Parentheses are not part of tuple display syntax, with the exception of "()", the empty tuple. Parenthesis are needed for tuple displays only to group the display in the context of a larger expression. This is my point about "*" not being a macro in the sense of m4 or Tex: the fact that the expression that in text is "*x" expands to something that in text we express as "y, z," doesn't mean they are the same thing as tuples in Python, even though we express the tuple in exactly the same text. In fact, when we write "y, z," *in a Python program* we are instructing Python to construct a *single tuple object*, but in my model of "*x", it does not construct an object *at all*: >>> *(1,2) File "<stdin>", line 1 SyntaxError: can't use starred expression here It is an expression that denotes a directive to a sequence constructor to "take objects from x and add them to the sequence". As I wrote before, I don't know if this model is how Python actually works, but it accounts for *all* of the behavior I've ever seen from starred expressions, including errors.

I see commas in both, so that's not the difference. Is there no way "*(1,2)," could equally be boxed up at exactly the same places where "1,2," can?

There's no "*" in "1,2," so it can play a different role from "*(1,2,)". I think it's useful that it does. Why do you think it's a good idea that *(1,2)* sometimes constructs an object, and other times does something wildly different?

Importantly, what problem may be caused by this in practice,

I'd have to change my model of what it does, or probably add an annoying special case "if a starred expression occurs in a context where its intended meaning is nonsense, and an actual tuple would do exactly the right thing, go ahead, pretend there's tuple syntax there, and box it up." My intuition is no more valuable than yours, but I think you have to admit that yours is the special case given what starred expressions are *needed* for, and so you admit I have the Zen on my side (for what that's worth).

or from what problem does SyntaxError currently raised there save us? For instance, if someone writes "s[*(1,2),]" in fact wanting "s[ [*(1,2),] ]" but forgets to box up "*(1,2),", then the same thing can happen for "s[ [1,2,] ]"

But these errors are exactly what you want to train people to expect to work! Every time I get syntax errors as above, my model is reinforced. If I don't get them, my model becomes more fragile and I'm *more* prone to such errors, because I start to believe that "*(1,2)" creates the tuple "(1,2)".

(i.e., it can be mistyped as "s[1,2,]" but without SyntaxError this time). It would at least be consistent if we got SyntaxError in both cases (namely, the syntax allowed only a single Python expression here), but if we don't want SyntaxError in the latter case, how may we want it in the former case?

I defy you to explain how the compiler or interpreter can distinguish any of those stipulated programmer errors from intended programs.

By the way, please note I wish "*(1,2)," to be treated like "1,2," only where the current syntax expects an expression list.

I think you're still thinking that "*" is an m4 macro, and it just isn't. Steve

Matsuoka Takuo :

Now, is "1,2," more boxed up than "*(1,2)," is? The *current* rule surely says the former is a tuple at some places and the latter is not,

Actually, this was wrong. First of all,

...

...

*(1,2), (1, 2)

Moreover, while the Language Reference says return_stmt ::= "return" [expression_list] at https://docs.python.org/3/reference/simple_stmts.html#the-return-statement things like return *(), are already allowed and () gets returned in this case, and so on! I haven't examined everything, but so far, subscription is the only place I've found where a starred expression in place of an expression list indeed raises SyntaxError. In particular, there really doesn't seem to be any reason why a starred expression should be rejected from any place where an expression list is accepted. In fact, rejection should _not_ be expected, it seems. My proposal at this point would be: (1) remove the definition of "expression_list" from the specification of the syntax (2) replace every occurrence of it in the specification with "starred_expression". At most places this seems to only recover the current behaviour. (Even if this idea does not survive in the end, I think the Language Reference should be fixed to describe the behaviour correctly. The actual behaviour is making better sense to me than what the Reference is describing now.) A minor question to be left then would be which new instance of "starred_expression" in the specification of the syntax may further be replaced with the optional one or "[starred_expression]", e.g., whether s[] would be better allowed and evaluated to s.__getitem__(()). This may be complicated. For example, I'm already used to returning None with return and so on. Even then, s[] doesn't seem very bad to me. Best regards, Takuo

Dear Steve, Thank you for your detailed explanation.

...

(i.e., it can be mistyped as "s[1,2,]" but without SyntaxError this time). It would at least be consistent if we got SyntaxError in both cases (namely, the syntax allowed only a single Python expression here), but if we don't want SyntaxError in the latter case, how may we want it in the former case?

I defy you to explain how the compiler or interpreter can distinguish any of those stipulated programmer errors from intended programs.

Sure, if you ever want any error raised in those cases, that's going to be SyntaxError to be always raised regardless of the programmer's intention. That's fine. But then if you don't want SyntaxError in the "latter" case, it in fact means you never want any error raised since SyntaxError is the only thing you could hope for anyway. So I could equivalently have asked "if we never want any error raised in the latter case, how may we want some error raised at least sometimes in the former case?". This may have been clearer to you, but it's an equivalent question. Anyway, I assume everything you say about "*(1,2)" is right, but it's not "*(1,2)" that I wanted to create an object, but, as I have indicated, it's things like "*iterable , " (with comma!), where the iterable may be "(1,2)". Just as in "1,2", the comma indicates the intention to create an object. For example,

...

...

*(1,2), (1, 2)

and another example:

...

...

*(), *(1,2) (1, 2)

I find it unfortunate SyntaxError you got with

...

...

*(1,2)

says "can't use starred expression here" since "*(1,2)" is not really a "starred expression" as defined in the Language Reference. I think this should be fixed, so have started a new thread on that, titled '''SyntaxError says: "can't use starred expression here", but its not the same "starred expression" defined in the Language Reference''', You are invited to comment on that! Best regards, Takuo

Matsuoka Takuo writes:

...

...

...

*(1,2), (1, 2)

Yes, this works, and now that I see you just want that to work in "a[*(1,2),]", I agree, I don't know why that is a syntax error. This works, of course: t = *(1,2), a[t] (in the sense that if a is a sequence you get a TypeError because the index isn't an integer or slice, but if it's a mapping you'll get the value corresponding to (1,2) or a KeyError because it's not in the mapping). I think it's not good that "a[*(1,2),]" gives a SyntaxError, but I don't know why it was made that way in the first place.

I find it unfortunate SyntaxError you got with

...

...

...

*(1,2)

says "can't use starred expression here" since "*(1,2)" is not really a "starred expression" as defined in the Language Reference.

I don't have time to go into that tonight but if the appropriate thread gets takeup I'll comment there. You could promote the issue by submitting a merge request. Steve

Dear Developers, After some findings and further thoughts through this thread, I have formulated a proposal as follows. (I thank everyone who has commented in this thread). For the necessary definitions, please look at https://docs.python.org/3/reference/expressions.html#subscriptions https://docs.python.org/3/reference/expressions.html#expression-lists https://docs.python.org/3/reference/expressions.html#slicings Difference from PEP 646 will be explained in a remark to follow. Note: In view of the definition of an expression statement and that of an assignment statement https://docs.python.org/3/reference/simple_stmts.html#expression-statements https://docs.python.org/3/reference/simple_stmts.html#assignment-statements I believe the correct definition of a starred expression actually used is starred_expression ::= expression | (starred_item ",")+ [starred_item] (that is, use "+" instead of "*"). Issues treated -------------- (1) The Language Reference is currently not describing the actual treatment of starred expressions precisely. For instance, the Language Reference says return_stmt ::= "return" [expression_list] at https://docs.python.org/3/reference/simple_stmts.html#the-return-statement but things like return *x, *y are accepted, which makes good sense and should be an officially supported use I think, but is not documented (in the Language Reference at least). (2) The rules on subscription of an object is not as simple as it can be. For instance, things like "a[*x,]" or "a[]" raises SyntaxError possibly unexpectedly. Proposal -------- (Z) Correct the definition of a starred expression in the Language Reference. (A) Syntax ------ Simplify the syntax as described in the Language Reference in the following manner. (A1) Remove the definition of "expression_list". (A2) Then replace every occurrence of it in the specification of the syntax with "starred_expression". In particular, change the definition of subscription to subscription ::= primary "[" starred_expression "]" Semantics --------- Reduce the interpretation of resulting newly valid expressions and statements to that of previously valid ones in the obvious manner. That is, interpret them as if each of the starred expressions in place of an expression list were packed in parentheses just around it. (B) Syntax ------ Change the definition of subscription further to subscription ::= primary "[" [starred_expression] "]" (meaning a starred expression there is now optional). Semantics --------- For subscription, without changing the meaning of the previously valid expressions, make the pair "[", "]" and the pair "[(", ")]" interchangeable. That is, interpret the brackets "[" and "]" for subscription as if "[" is a shorthand for .__getitem__(( (or .__class_getitem__(( depending on the object in front of it) and "]" is a shorthand for )) at the time of evaluation, and similarly at assignment and deletion in the obvious appropriate way using the methods __setitem__ and __delitem__ respectively. (C) Syntax ------ Change the definition of a slicing to slicing ::= primary "[" [slice_expression] "]" slice_expression ::= slice_item | (starred_slice_item ",")+ [starred_slice_item] starred_slice_item ::= starred_item | slice_item Semantics --------- Reduce the interpretation of a slicing to that of a subscription in the usual way, namely, by replacing every item between the brackets which is a proper slice with an expression for the corresponding slice object. Remarks ------- (1) The step (A) would in fact do most of the step (B). For instance, after the step ((Z) and) (A), "a[*x,]" would be a valid expression equivalent to the already valid expression a[(*x,)] satisfying (B). The only thing (B) would add to (A) in concrete terms is it would make a[] a valid expression equivalent to "a[()]" (where "a" may of course be replaced by any Python "primary"). (2) The proposal disagrees with PEP 646 in that, after our steps, the expression of the form "a[*x]" will not get valid. In particular, unlike with PEP 646, we won't have e.g., a[*[y]] as a valid expression which is _not_ equivalent to a[y] The details of PEP 646 on the subject can be found at https://www.python.org/dev/peps/pep-0646/#star-expressions-in-indexes (In either way, "a[*[y],]" would be valid and equivalent to "a[y,]".) Thats' it. I hope to hear your thoughts. Best regards, Takuo Matsuoka