[prev in list] [next in list] [prev in thread] [next in thread]
List: python-ideas
Subject: [Python-ideas] Re: allow initial comma
From: Todd <toddrjen () gmail ! com>
Date: 2021-03-15 12:53:20
Message-ID: CAFpSVpLOmTjG_jo8WLgeJW334a-yq4gKEHV30rjOTfo9aPMF=w () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Mar 15, 2021, 06:15 Roland Puntaier via Python-ideas <
python-ideas@python.org> wrote:
> On Fri 21Mar12 14:27, Paul Bryan wrote:
> >It seems your proposal is intended to address an aesthetic concern. Is
> >there a case where using a leading comma would make something
> >actually easier or more intuitive to express over the use of trailing
> >comma?
>
> Aesthetic Concern: No
> =====================
>
> It might seem an aesthetic concern,
> but I thought a bit about it,
> and I don't think it is.
>
> People here have uttered aesthetic concerns. I have not.
> I would like aesthetic concerns to be left out of discussion,rather.
>
> Aesthetics is everybody's right to personal preferences.
> My concern is more that someone's aesthetic concern has
> impact on the practical needs of many.
> My proposal does not restrict anybody's aesthetic preferences.
>
> I can't understand those people that argue about style, like PEP8.
> If in a team, through local agreement, you decide to follow it strictly,
> do it, but don't dictate it on the millions of programs
> or command line input that are for personal use only.
>
> Don't confuse style with syntactic necessities.
>
> For many cases of error in language syntax,
> the only reason, is to reserve the construct for future use.
> Else, if a reasonable interpretation is possible, do it.
> It is like communicating between people.
> Some waste time asking back or reporting an error,
> if thinking instead could make perfect reason of the message.
> Only if there is a real ambiguity, clarify it by asking back.
>
> The back and forth is much more time consuming
> than a thoughtful interpretation.
>
> I hesitate to call this proposal a language change.
> It is rather a syntactic allowance,
> like that of the trailing comma before the terminating token.
>
> So:
>
> - Can `x=[,1,2]` possibly be used for some future language feature,
> liking making `[,` a operator of its own?
> Considering that one has already decided that `,]` will not be allowed
> to have a separate meaning in the future,
> then, so should neither `[,`.
>
> - Can `x=[,1,2]` be misinterpreted?
> As `,]` has found a reasonable interpretation, so can `[,`.
>
> Further:
>
> - Will interpretation be slower through such an allowance?
> That needs detailed analysis, that would need to follow.
> But since `,]` handling is considered in the interpretation,
> so could `[,`.
>
> - A `x=2,` is a tuple. Should `x=,2` be also a tuple?
> Yes. `,` can be seen as a tuple constructing operator,
> unless there is `[` and `{`,
> which change the interpretation to list or set/dict.
> `()` is expression grouping.
>
> Can the proposal be generalized to other operators?
> ===================================================
>
> Yes.
>
> Please, don't mix in aesthetics, though,
> like only considering trailing cases.
>
> One should distinguish:
>
> - `,` is a operator on the syntactic layer only.
>
> - `+`, `*`, and the like, are operators,
> that map to operators on layers below.
> Nevertheless, during parsing,
> they are operators in the syntactic layer, too.
>
> Syntactic operators can have neutral elements.
> The neutral element on the syntactic layer is "nothing there".
> This "nothing" is like the `0` for `+` or the `1` for `*`,
> but on the parsing/syntactic layer.
>
> The neutral element makes the operation naught.
> In the AST it would not be there any more.
>
> `2,3` is not the same as `3,2`.
> The `,` operator is not commutative.
> The neutral element, in this case, is applicable on both sides,
> even if non-commutative,
> because it is not there in the AST any more, anyway:
> 2, == ,2.
>
> For operators from lower level the behavior of that lower level operator
> needs to be considered in the parsing layer.
>
> - `+2` is the same as `2+`, because `0+2` is the same `2+0`.
> - But, `-2` is not the same as `2-`, because `0-2 ‡ 2-0`.
>
You missed the second, and much more important, part of that post:
"Is there a case where using a leading comma would make something actually
easier or more intuitive to express over the use of trailing comma?"
Python language changes are not done just on the off chance someone might
use them at some point, they must provide a significant demonstrable
benefit in real-world code. I don't see where you do that in any of your
posts. This is a bare minimum requirement.
[Attachment #5 (text/html)]
<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 15, 2021, \
06:15 Roland Puntaier via Python-ideas <<a \
href="mailto:python-ideas@python.org">python-ideas@python.org</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri 21Mar12 \
14:27, Paul Bryan wrote:<br> >It seems your proposal is intended to address an aesthetic concern. \
Is<br> >there a case where using a leading comma would make something<br>
>actually easier or more intuitive to express over the use of trailing<br>
>comma?<br>
<br>
Aesthetic Concern: No<br>
=====================<br>
<br>
It might seem an aesthetic concern,<br>
but I thought a bit about it,<br>
and I don't think it is.<br>
<br>
People here have uttered aesthetic concerns. I have not.<br>
I would like aesthetic concerns to be left out of discussion,rather.<br>
<br>
Aesthetics is everybody's right to personal preferences.<br>
My concern is more that someone's aesthetic concern has<br>
impact on the practical needs of many.<br>
My proposal does not restrict anybody's aesthetic preferences.<br>
<br>
I can't understand those people that argue about style, like PEP8.<br>
If in a team, through local agreement, you decide to follow it strictly,<br>
do it, but don't dictate it on the millions of programs<br>
or command line input that are for personal use only.<br>
<br>
Don't confuse style with syntactic necessities.<br>
<br>
For many cases of error in language syntax,<br>
the only reason, is to reserve the construct for future use.<br>
Else, if a reasonable interpretation is possible, do it.<br>
It is like communicating between people.<br>
Some waste time asking back or reporting an error,<br>
if thinking instead could make perfect reason of the message.<br>
Only if there is a real ambiguity, clarify it by asking back.<br>
<br>
The back and forth is much more time consuming<br>
than a thoughtful interpretation.<br>
<br>
I hesitate to call this proposal a language change.<br>
It is rather a syntactic allowance,<br>
like that of the trailing comma before the terminating token.<br>
<br>
So:<br>
<br>
- Can `x=[,1,2]` possibly be used for some future language feature,<br>
liking making `[,` a operator of its own?<br>
Considering that one has already decided that `,]` will not be allowed<br>
to have a separate meaning in the future,<br>
then, so should neither `[,`.<br>
<br>
- Can `x=[,1,2]` be misinterpreted?<br>
As `,]` has found a reasonable interpretation, so can `[,`.<br>
<br>
Further:<br>
<br>
- Will interpretation be slower through such an allowance?<br>
That needs detailed analysis, that would need to follow.<br>
But since `,]` handling is considered in the interpretation,<br>
so could `[,`.<br>
<br>
- A `x=2,` is a tuple. Should `x=,2` be also a tuple?<br>
Yes. `,` can be seen as a tuple constructing operator,<br>
unless there is `[` and `{`,<br>
which change the interpretation to list or set/dict.<br>
`()` is expression grouping.<br>
<br>
Can the proposal be generalized to other operators?<br>
===================================================<br>
<br>
Yes.<br>
<br>
Please, don't mix in aesthetics, though,<br>
like only considering trailing cases.<br>
<br>
One should distinguish:<br>
<br>
- `,` is a operator on the syntactic layer only.<br>
<br>
- `+`, `*`, and the like, are operators,<br>
that map to operators on layers below.<br>
Nevertheless, during parsing,<br>
they are operators in the syntactic layer, too.<br>
<br>
Syntactic operators can have neutral elements.<br>
The neutral element on the syntactic layer is "nothing there".<br>
This "nothing" is like the `0` for `+` or the `1` for `*`,<br>
but on the parsing/syntactic layer.<br>
<br>
The neutral element makes the operation naught.<br>
In the AST it would not be there any more.<br>
<br>
`2,3` is not the same as `3,2`.<br>
The `,` operator is not commutative.<br>
The neutral element, in this case, is applicable on both sides,<br>
even if non-commutative,<br>
because it is not there in the AST any more, anyway:<br>
2, == ,2.<br>
<br>
For operators from lower level the behavior of that lower level operator<br>
needs to be considered in the parsing layer.<br>
<br>
- `+2` is the same as `2+`, because `0+2` is the same `2+0`.<br>
- But, `-2` is not the same as `2-`, because `0-2 ‡ 2-0`.<br></blockquote></div></div><div \
dir="auto"><br></div><div dir="auto">You missed the second, and much more important, part of that \
post:</div><div dir="auto"><br></div><div dir="auto">"Is there a case where using a leading comma \
would make something actually easier or more intuitive to express over the use of trailing \
comma?"</div><div dir="auto"><br></div><div dir="auto">Python language changes are not done just on \
the off chance someone might use them at some point, they must provide a significant demonstrable benefit \
in real-world code. I don't see where you do that in any of your posts. This is a bare minimum \
requirement.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> </blockquote></div></div></div>
_______________________________________________
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/JLUSJM27LDUR446J2LQZZPYFVT5WNH4B/
Code of Conduct: http://python.org/psf/codeofconduct/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic