Dear Guido van Rossum,
Thank you for bringing the PEP's to my attention.
The idea of PEP 637 on a[*x] is different from my idea. The PEP's idea
appears making subscription analogous to function calls. In the end,
a[*x] would have been equivalent to
a[tuple(x)]
if the PEP had been adopted. a[*x] in PEP 646 is similar, but has more
restrictions on what formulas can fill the brackets. I understand only
the a[*x] part of PEP 637 has been found of enough interest so
far. For this part, 637 seems better than 646 in that it looks
simpler.
A concern about pursuing analogy with function calls may be there
already is a difference, namely, a[x] and a[x,] are not
equivalent while f(x) and f(x,) are. In particular, a[*(x, )] not
being equivalent to a[x] might at least be confusing.
On the other hand, my idea was just a slight change from the current
syntax by simple two steps described in my previous post. In
particular,
a[*x]
would remain invalid, but
a[*x, ]
would be valid and equivalent to a[tuple(x)] (just as
*x,
at certain places is equivalent to tuple(x) ).
PEP 637 has proposed to leave a[] invalid, which in their scheme seems
confusing to me since a[*()] would be valid (and equivalent to
a[tuple(())] or a[()] ), as well as seems to go against the analogy to
calling of functions: f() is valid, just not equivalent to f(()) .
Best regards,
Takuo
2021年8月16日(月) 10:58 Guido van Rossum

Have you seen PEP 637? IIRC it has discussions on a[] and a[*x]. Note that it was rejected, but the idea of a[*x] is being resurrected for PEP 646.

On Fri, Aug 13, 2021 at 5:43 AM Matsuoka Takuo

wrote: Dear Developers,

Given a subscriptable object s, the intended rule for the notation for getting an item of s seems that, for any expression {e}, such as "x, ", s[{e}] (i.e., s[x, ] if {e} is "x, ") means the same as s[({e})] (i.e., s[(x, )] in the considered case), namely, should be evaluated as s.__getitem__(({e})) (or s.__class_getitem__(({e})) when that applies). If this is the rule, then it looks simple and hence friendly to the user. However, there are at least two exceptions:

(1) The case where {e} is the empty expression "": The expression s[] raises SyntaxError instead of being evaluated in the same way as s[()] is.

(2) The case where {e} contains "*" for unpacking: An expression containing the unpacking notation, such as s[*iterable, ] raises SyntaxError instead of being evaluated in the same way as s[(*iterable, )] in this example, is.

Are these (and other if any) exceptions justified? If not, I propose having the described rule to have full effect if that would simplify the syntax. This would affect currently working codes which rely on SyntaxError raised in either of the described ways (through eval, exec or import??). I wonder if reliance on SyntaxError in these cases should be supported in all future versions of Python.

Best regards, Takuo Matsuoka _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/V2WFMN... Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido) Pronouns: he/him (why is my pronoun here?)