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