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 <gu...@python.org>:
>
> 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 <motogeom...@gmail.com> 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-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/V2WFMNVJLUBXVQFPNHH4TJNRYNPK2BKJ/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him (why is my pronoun here?)
_______________________________________________
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/YOONIQ6EBDQYHS3JP4Q3ENIYZCGYJEE7/
Code of Conduct: http://python.org/psf/codeofconduct/
