[Python-ideas] Re: Notation for subscripts.
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
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
[Python-ideas] Re: Notation for subscripts.
Dear ChrisA, Steve, Thank you for your comments. ChrisA, it was off the main topic, but for me, the issue was just one of wording in the exception message. It's good to hear changes to wording can be done without compatibility concerns. I'll find out about merge request suggested by Stephen J. Turnbull. Steve, I think care is necessary to decide whether the validity of > t = *(1,2), > a[t] suffices to justify the expression "a[*(1,2),]". It could only justify a[ (*(1,2),) ] Note for example, >>> s = (1,2) >>> t = *s, >>> [t] == [*s,] False Another exmaple: >>> t = *s, >>> f(t) == f(*s,) False However, for an appropriate object "a", we have >>> t = *(1,2), >>> a[t] == a[1,2] True which must be a special thing. I think this should be compared with >>> t = *s, >>> (t) == (*s,) True (In the above, I constructed "a" (and "f") by >>> def f(*args, **kwargs): ... return locals() ... >>> class A: ... @property ... def __getitem__(self): ... return f ... >>> a = A() ) Here's another piece of similarity. >>> [1,] == [1] True >>> f(1,) == f(1) True >>> (1,) == (1) False >>> a[1,] == a[1] False Thank you for your suggestion to submit a merge request. Best regards, Takuo On Fri, 20 Aug 2021 at 01:33, Stephen J. Turnbull wrote: > > 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 > ___ 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/UOCPFBJG4H5XBMVII7WBJ62VXW2D5KJC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Notation for subscripts.
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 ___ 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/XPBMDKG3AUM42EBO2CAKCAYY42FMREFG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Notation for subscripts.
On Thu, Aug 19, 2021 at 11:27 PM Matsuoka Takuo wrote: > > 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! Is the issue just one of wording in the exception message, or are you asking for a change of functionality? In your final example, you've never said that you're creating a tuple, so it's correct to get a SyntaxError. I'm confused as to whether you're asking for this to have meaning, or if instead you are simply proposing a change to wording. Changes to wording can definitely be done, and aren't a major backward or forward compatibility concern. ChrisA ___ 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/YCT4EQAABSDAHIQ65NXQZI3SSC6FKNV7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Notation for subscripts.
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 ___ 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/J7WDSY7JTC64WQZ6YWB5HWLADXPK2KQZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Notation for subscripts.
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-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/
[Python-ideas] Re: Notation for subscripts.
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 ___ 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/6CKPSNDUPMA2HMX2I25ECFEQ4F4CD2XB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Notation for subscripts.
I believe this is useful since this syntax is developed in some
libraries as an internal DSL. At least I have seen it in pandas, a
library handling tables.
df[(df['a'] < df['b']) & (df['b'] < df['c'])]
df[~df['a'].isin(df['b'])]
df[df['b'].isin(df['a']) & (df['c'] < df['d'])]
More examples in {[pandas-doc-url]/user_guide/indexing.html}.
On 13/08/2021 20:18, 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-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/
___
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/S2QENKAIRJKZJWH77FUPFPVNNS3VHAWY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Notation for subscripts.
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 "", 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 ___ 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/W6OL74XJEAQU2QYETOSRZGEW5ZXWY3JK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Notation for subscripts.
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-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] Re: Notation for subscripts.
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 ___ 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/RKTLNFTKVRUPVEUIINGBO72EENX4MYH3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Notation for subscripts.
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/
[Python-ideas] Re: Notation for subscripts.
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 ___ 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/UVIJEMNOH75LJIVLFRWQSDTIYO2ZLBKX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Notation for subscripts.
On 2021-08-13 at 23:18:29 +1100,
Matsuoka Takuo wrote:
> 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})]
If e is an expression, then s[e] means s[e].
Sometimes, e happens to be a tuple, but Python doesn't create a tuple
just to call __getitem__. The following expression:
x,
is a tuple all by itself. Also:
(x,)
is that same tuple.
> (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 "":
There is no such thing as an "empty expression." "" is a string
containing no characters.
> The expression
> s[]
> raises SyntaxError ...
Because there is no expression (which is different from a hypothetical
"empty expression."
> ... instead of being evaluated in the same way as
> s[()] is.
() is a tuple with no elements, just as [] is a list with no elements,
and "" is a string with no elements.
___
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/ZCSPKRQMVJ5RCR4WD62QIGLPYPJOFE4P/
Code of Conduct: http://python.org/psf/codeofconduct/
