Matsuoka Takuo writes: > 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
I would not have expected that at all, as *(1,2) is macro-like syntax that expands to an "unboxed" sequence of objects (and must do so, to serve its purpose of being "spliced into" a sequence being constructed), while 1,2 is expression syntax that is evaluated to a single object (which happens to be a sequence of objects "boxed up" in a tuple), and the parentheses may be omitted if the only possible interpretation is "tuple of all comma-separated objects". But for *(1,2), it could be that, but because it is "unboxed", it could also be "list of all comma-separated objects". Again, it is *not* a macro, substituting the text "1, 2" for the text "*(1,2)", expanding any newly added *-constructs recursively, and finally the constructor is executed on the resulting text. Like everything else in Python, it is executed on objects. What's unique about it is that it produces them "unboxed", ready for splicing (or inversely collecting a slice, in the case of a *-ed assignment target). Now, that's not the Language Reference (at least, I didn't consult it!), that's my intuition about *-constructs. But as far as I can tell it accounts for all their behavior, including this SyntaxError. Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OCM34VLWM7OH3U6BCKLZQ5RDJTPFT6N6/ Code of Conduct: http://python.org/psf/codeofconduct/
