[Python-ideas] Re: allow initial comma

[Hans Ginzel]

On Tue, Mar 16, 2021 at 08:28:05AM -0700, Guido van Rossum wrote:

Personally, I'd like to remind you that when I designed Python my ideal was
to use punctuation in ways that are similar to the way it is used in plain
English, with exceptions only for forms commonly found in many other
programming languages such as foo.bar. Leading with a comma is most
definitely not something one would do in English.


Why not continue evolving from natural language to a programming one?
It was good approach at beginning but is nowadays the argument still relevant?
Why not to integrate programming experiences into programming language?

H.

PS:
Larry Wall was also designing Perl by natural English language.
https://bigthink.com/videos/why-perl-is-like-a-human-language
He has brought e.g. the practical
statement if condition
syntax, which is natural and
emphases the statement not the (special) condition.
___
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/JQ24HUYKHN3IYZCSE2DX4EU3IMVRONAV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Hans Ginzel]

Thank you Roland, for that idea!

On Tue, Mar 16, 2021 at 01:52:48PM +0100, Roland Puntaier via Python-ideas 
wrote:

On Mon 21Mar15 22:24, Stephen J. Turnbull wrote:

Roland Puntaier via Python-ideas writes:


Aesthetic Concern: No
=

It might seem an aesthetic concern,
but I thought a bit about it,
and I don't think it is.


I has been also conservative about leading commas.
But with huge using and generating of sql files I came to „taste“ of it.
In SQL it is very common and aesthetic and practical to write the comma
on the beginning of a line:

SELECT  …
FROM(
 SELECT column1
 ,  column2
 ,  column3
 FROM   t1
JOIN t2 ON …
 )  AS q1
 …

You can easily add or remove columns.
In addition you see the relation corresponding SELECT and FROM keywords in 
(indented) subqueries.
The possibility of leading comma before the first column is also very missing.


As you hinted, possibly add an option line above/before.
One would use it only for lines, of course. One would not write `[,1,2]`,
but one possibly would write

def long_fun(
   , long_option = 'long_expression_for_default'.split('_'),
   , option1=1
   )
   :pass


Nice. Also useful for huge dict/mappings definitions.


Can the proposal be generalized to other operators?
===

Yes.


I find the case for allowing logical line continuation by a leading
operator stronger than allowing a leading comma in a sequence display.
But I don't particularly *want* it, so I'll leave it to you to make
that argument if you want to.

Allowing operators to start an expression already has a meaning in
some cases, but I don't see a good argument for establishing a general
rule that a missing operand is the identity, even though that works
for leading "+" and "-".  It's already not the case for "*" and "**",
and "~" has no binary counterpart.


This is not my proposal, but I would welcome it.


I also.

H.
___
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/24KMKOC6UQIOODXWGCJGEJLIRZPW745U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Gerrit Holl]

Hi,

On Fri, 12 Mar 2021 at 15:12, Paul Moore  wrote:
> This layout style is not something I've ever seen used in "real life",
> and I don't think it's something that should be encouraged, much less
> added to the language.

> More likely because there are two common schools of thought - lists
> have punctuation *separating* items, and lists have punctuation
> *terminating* items. I don't even know a commonly used term for the
> idea of having something *before* each item.

If Roland wants to prepend each item of his list, he can always write

>>> yaml.load(io.StringIO("""
... - a
... - b
... - c"""))

giving ["a", "b", "c"] ;-)

The point being: it's actually very common to prepend each item of a
list with a character, arguably more common than after each item.
That character may be '-', '•', '∗', but I've never seen ',' used.  In
most cases, each item in such lists appears on a separate line.  Apart
from the YAML example given above, this style is used in many
ReST/Markdown/ASCIIdoc/wikitext flavours and on whiteboards and
notebooks in English, Russian, Swahili, and Volapük around the world.

Regards,
Gerrit.
___
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/UG32SOALEP5IVGTKGPQMJC54ASH7EH3F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Richard Damon]

On 3/16/21 8:22 AM, Roland Puntaier via Python-ideas wrote:
> On Mon 21Mar15 15:18, Paul Bryan wrote:
>> On Mon, 2021-03-15 at 11:13 +0100, Roland Puntaier via Python-ideas
>> wrote:
>>
>>> 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.
>>
>> If implemented, such a proposal would in fact require a change to the
>> language specification.
>
> Yes. What I meant is, that it is minor,
> equivalent to the `,]` change.
>
>>
>>> 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 `[,`.
>>
>> It would be helpful to me to understand what friction you're currently
>> experiencing without such a change. I'm still struggling to appreciate
>> what the benefit would be, beyond aesthetic preference.
>
> I'd like to write
>
> def my_long_function_name(
>     , my_long_option_2 = "some default expression 1".split()
>     , my_long_option_1 = "some default expression 1".split()
>     ):
>     pass
>
> Then, I'd like to change the order of the lines without having to care
> to remove and add a comma.
>
> To allow `,]` was motivated by aesthetic preferences (PEP8).
> To allow both `[,`, and `,]` is aesthetically more neutral.
>
> So, the proposal is based on the already done `,]` language feature.
> The proposal adds some syntactic flexibility,
> which avoids errors in situations like the one described. 


My thought is that there is a line in the Zen

> There should be one-- and preferably only one --obvious way to do it.
That says that the langauge doesn't desire to be aesthetically neutral,
but will intentionally choose a preferred way to do something. Other
ways may be possible, if there is a good reason (and sometimes that is
just due to backwards compatibility when a better way to do something in
discovered).

This rule is even literally baked into the language due to 'import this'

I think this means you need a stronger motivation than you just want
another way to do the same thing,

-- 
Richard Damon

___
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/US5MJJA2KTE6QVCX5GR5ORZWLSICX6GO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Guido van Rossum]

Hi Roland,

Can you please give up on this particular idea? You've given it a fair try,
and nobody is showing any interest in changing Python to match your
proposal. That's usually a good indication that it will Never Happen, and
if you keep arguing beyond that point you tend to be written off as out of
tune.

Personally, I'd like to remind you that when I designed Python my ideal was
to use punctuation in ways that are similar to the way it is used in plain
English, with exceptions only for forms commonly found in many other
programming languages such as foo.bar. Leading with a comma is most
definitely not something one would do in English.

I hope to see you continue brainstorming on other ideas.

--Guido

On Fri, Mar 12, 2021 at 5:21 AM roland.puntaier--- via Python-ideas <
python-ideas@python.org> wrote:

> I had posted this as https://github.com/python/peps/issues/1867
> The discussion so far is below.
>
> Please make some arguments.
>
> The major point to me is, that the symmetry is broken,
> which leads to extra editing actions, like removing the comma in the first
> line.
> I guess, this was the reason to allow the comma after the last line/entry:
> `[1,2,]`.
> ``[,1,2]`` should also be allowed, too.
>
> The best argument is one that says: less or more effort in this or that
> situation.
> For example, with `[1,2,]`, in line-wise formatting,
> one can do without special action at the last line (removing the comma
> there).
>
> All code from previous versions of Python would still work
> after a `[,1,2]` syntax allowance were introduced.
>
>
>
> =
> rpuntaie wrote:
>
> =
>
> Allow initial comma
> ===
>
> Final comma works:
>
> t = (
>  1,
>  2,
> )
> x = [
>  1,
>  2,
> ]
> y = {
>  1,
>  2,
> }
> z = {
>  1:11,
>  2:22,
> }
> def fun(
>   a,
>   b,
>  ):
>   pass
>
> Initial comma does not work:
>
> t = (
>  , 1
>  , 2
> )
> x = [
>  , 1
>  , 2
> ]
> y = {
>  , 1
>  , 2
>  }
> z = {
>  , 1:11
>  , 2:22
>  }
> def fun(
>  , a
>  , b
>  ):
>   pass
>
>
> To make the syntax symmetric in this regard\
> gives more freedom to format the code.
>
> I occasionally found the restriction an unnecessary nuisance.
>
> Before writing a PEP, I would like to discuss,
>
> -   whether something like that has been proposed already?
> -   what counter-arguments there could be?
>
>
> =
> pxeger wrote:
>
> =
>
> This is not the appropriate place to propose language changes.
> Try the [python-ideas](
> https://mail.python.org/mailman3/lists/python-ideas.python.org/)
> mailing list. However, I don't think you'll get anyone to agree.
>
> What kind of code style are you using where you want to put commas at
> the start of the line? That is totally non-standard
> (see [PEP 8](https://www.python.org/dev/peps/pep-0008)), ugly, and
> confusing.
>
> Arbitrary symmetry is not a good reason for changing the language. We
> don't have a `tnirp` function just for the sake of symmetry with
> `print` because it would be pointless and add extra complication
>
>
>
> =
> rpuntaie wrote:
>
> =
>
> I surely agree, that not ignoring the sequence is essential. Else one
> would loose identifier space and thus information. I would never have
> the idea to make all permutations of `p.r.i.n.t` point to the same
> function. Therefore you just made a bad example.
>
> But the comma is just a separator. Why did they allow to have the
> comma before a closing bracket/parenthesis/brace? Because of symmetry
> between lines, is my guess.
>
> Occasionally one sees many spaces just the have the final comma
> aligned vertically. That could be avoided by placing the comma at the
> beginning.
>
> I personally also have a macro in the editor that evaluates a line in
> the parameter list, but drops an initial comma before doing that.
> Therefore this is my preferred formatting.
>
> I don't think that [PEP](https://www.python.org/dev/peps/pep-0008)
> is wrong. I just don't want to be restricted by unnecessary rules.
> Rules need to have a reason beyond someone dictating them. If that is
> the case, I follow them, because I see the reason, but not because
> someone dictates them.
>
> I'll go to
> [Python Ide as](
> https://mail.python.org/mailman3/lists/python-ideas.python.org/),
> 

[Python-ideas] Re: allow initial comma

[Ned Batchelder]

On 3/16/21 8:22 AM, Roland Puntaier via Python-ideas wrote:

I'd like to write

def my_long_function_name(
    , my_long_option_2 = "some default expression 1".split()
    , my_long_option_1 = "some default expression 1".split()
    ):
    pass



Why not write this instead?:

   def my_long_function_name(
    my_long_option_2="some default expression 1".split(),
    my_long_option_1="some default expression 1".split(),
    ):
    pass

It has all the advantages you are looking for, plus it isn't 
odd-looking, and it's already supported.


--Ned.


___
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/N5WEMH7FMX5RX55YH2YV6OBDBWLAQL5L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Todd]

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.
___
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/JLUSJM27LDUR446J2LQZZPYFVT5WNH4B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Eric V. Smith]

On 3/12/2021 4:42 PM, Paul Bryan wrote:
Using your example (thanks, seeing a concrete example is helpful) it 
appears you can do it the SQL way in Python too:


x = (1
,2
,3
)


Right. It's just that no one would want to!

Eric




On Fri, 2021-03-12 at 16:35 -0500, Eric V. Smith wrote:

On 3/12/2021 3:37 PM, Greg Ewing wrote:

On 13/03/21 5:02 am, Ned Batchelder wrote:

I think the only reason anyone ever used leading commas to begin with
was because of languages that didn't allow a final trailing comma.
In those worlds, to keep the editing smooth, people moved the commas
to the beginning of the line,


Which doesn't help unless the language allows leading commas that
are ignored, and I've never seen a language like that.


Things are added to the end of lists more often than to the front. For
example, column names in SQL or parameters in Python.

Because SQL doesn't allow trailing commas, I've often seen things
written as:

select a
,b
,c
,d

Then when you want to add "e" to the end, you just duplicate the ",d"
row and change "d" to "e".

For Python, you'd do:

select(a,
b,
c,
d,
)

And then similarly add "e," to the end.

Anyway, since Python already allows trailing commas, I see no need to
add leading ones. Which is a feature I've never seen in any language,
either. And it would make it slightly easier to leave off the first
parameter.

Eric

___
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/R6AU26PL4QK5LFMW25PP2VUVLFSTDGX6/ 

Code of Conduct: http://python.org/psf/codeofconduct/ 




--
Eric V. Smith

___
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/TJVRA2VUX6UIK4KQGZ47W44OFCW65CM6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Paul Bryan]

Using your example (thanks, seeing a concrete example is helpful) it
appears you can do it the SQL way in Python too:

x = (1
,2
,3
)


On Fri, 2021-03-12 at 16:35 -0500, Eric V. Smith wrote:
> On 3/12/2021 3:37 PM, Greg Ewing wrote:
> > On 13/03/21 5:02 am, Ned Batchelder wrote:
> > > I think the only reason anyone ever used leading commas to begin
> > > with 
> > > was because of languages that didn't allow a final trailing
> > > comma.  
> > > In those worlds, to keep the editing smooth, people moved the
> > > commas 
> > > to the beginning of the line,
> > 
> > Which doesn't help unless the language allows leading commas that
> > are ignored, and I've never seen a language like that. 
> 
> Things are added to the end of lists more often than to the front.
> For 
> example, column names in SQL or parameters in Python.
> 
> Because SQL doesn't allow trailing commas, I've often seen things 
> written as:
> 
> select a
> ,b
> ,c
> ,d
> 
> Then when you want to add "e" to the end, you just duplicate the ",d"
> row and change "d" to "e".
> 
> For Python, you'd do:
> 
> select(a,
> b,
> c,
> d,
> )
> 
> And then similarly add "e," to the end.
> 
> Anyway, since Python already allows trailing commas, I see no need to
> add leading ones. Which is a feature I've never seen in any language,
> either. And it would make it slightly easier to leave off the first 
> parameter.
> 
> Eric
> 
> ___
> 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/R6AU26PL4QK5LFMW25PP2VUVLFSTDGX6/
> 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/TDAA4F7S55KS2UHDKJTN6SFBHKDGYTYF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Eric V. Smith]

On 3/12/2021 3:37 PM, Greg Ewing wrote:

On 13/03/21 5:02 am, Ned Batchelder wrote:
I think the only reason anyone ever used leading commas to begin with 
was because of languages that didn't allow a final trailing comma.  
In those worlds, to keep the editing smooth, people moved the commas 
to the beginning of the line,


Which doesn't help unless the language allows leading commas that
are ignored, and I've never seen a language like that. 


Things are added to the end of lists more often than to the front. For 
example, column names in SQL or parameters in Python.


Because SQL doesn't allow trailing commas, I've often seen things 
written as:


select a
,b
,c
,d

Then when you want to add "e" to the end, you just duplicate the ",d" 
row and change "d" to "e".


For Python, you'd do:

select(a,
b,
c,
d,
)

And then similarly add "e," to the end.

Anyway, since Python already allows trailing commas, I see no need to 
add leading ones. Which is a feature I've never seen in any language, 
either. And it would make it slightly easier to leave off the first 
parameter.


Eric

___
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/R6AU26PL4QK5LFMW25PP2VUVLFSTDGX6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Greg Ewing]

On 13/03/21 5:02 am, Ned Batchelder wrote:
I think the only reason anyone ever used leading commas to begin with 
was because of languages that didn't allow a final trailing comma.  In 
those worlds, to keep the editing smooth, people moved the commas to the 
beginning of the line,


Which doesn't help unless the language allows leading commas that
are ignored, and I've never seen a language like that.

--
Greg
___
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/4E5NN7ENLKMOS2IBAPC7FUXIKU3JBFZE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Chris Angelico]

On Sat, Mar 13, 2021 at 3:28 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> For exmaple, if I have a multiline list like this:
>
> x = [
>   1,
>   2
> ]
>
> and add a new element to the end, then I end up with the diff including
> the 2 even though I didn't change the 2.  But if I had had a trailing
> comma, then the diff only shows the new entry.
>
> I see a lot of SQL with the commas at the beginnings of the lines
> (mostly, I think, due to SQL's syntax), but it solves the same problem.

Also in JSON, and for the same reason: the syntax disallows the
trailing comma. There is no reason to create the awkwardness if
trailing commas are accepted.

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/TS7P3FBU6ICLM3XYPC4J3JZEUH5X7Q5N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[2QdxY4RzWzUUiLuE]

On 2021-03-12 at 11:02:50 -0500,
Ned Batchelder  wrote:

> I think the only reason anyone ever used leading commas to begin with
> was because of languages that didn't allow a final trailing comma.  In
> those worlds, to keep the editing smooth, people moved the commas to
> the beginning of the line, breaking with every comma-tradition.

Allowing a trailing comma makes historical diffs shorter and easier to
read.

For exmaple, if I have a multiline list like this:

x = [
  1,
  2
]

and add a new element to the end, then I end up with the diff including
the 2 even though I didn't change the 2.  But if I had had a trailing
comma, then the diff only shows the new entry.

I see a lot of SQL with the commas at the beginnings of the lines
(mostly, I think, due to SQL's syntax), but it solves the same problem.

> I don't see a reason to make that odd style easier.

I like allowing a trailing comma (for all of the previously stated
reasons), but I agree that "we" (except the SQL people!) seem to have
settled on trailing delimiters rather than leading delimiters, probably
because of the way we write human languages.
___
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/BQIIQFR4W723C6DQDTQIRXKCMCZHKO4N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Paul Moore]

On Fri, 12 Mar 2021 at 16:06, Ned Batchelder  wrote:
>
> I think the only reason anyone ever used leading commas to begin with was 
> because of languages that didn't allow a final trailing comma.  In those 
> worlds, to keep the editing smooth, people moved the commas to the beginning 
> of the line, breaking with every comma-tradition.

Yes, I've seen it in SQL. But even there, it isn't used before the
*first* element of a list.

> I don't see a reason to make that odd style easier.

Agreed.
Paul
___
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/DA7K5IB5XBCJFQKERQWZKARCIZLCPHQC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: allow initial comma

[Ned Batchelder]

I think the only reason anyone ever used leading commas to begin with 
was because of languages that didn't allow a final trailing comma.  In 
those worlds, to keep the editing smooth, people moved the commas to the 
beginning of the line, breaking with every comma-tradition.


I don't see a reason to make that odd style easier.

--Ned.

On 3/12/21 9:27 AM, 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?


On Fri, 2021-03-12 at 10:34 +, roland.puntaier--- via Python-ideas 
wrote:
I had posted this as https://github.com/python/peps/issues/1867 


The discussion so far is below.

Please make some arguments.

The major point to me is, that the symmetry is broken,
which leads to extra editing actions, like removing the comma in the 
first line.
I guess, this was the reason to allow the comma after the last 
line/entry: `[1,2,]`.

``[,1,2]`` should also be allowed, too.

The best argument is one that says: less or more effort in this or 
that situation.

For example, with `[1,2,]`, in line-wise formatting,
one can do without special action at the last line (removing the 
comma there).


All code from previous versions of Python would still work
after a `[,1,2]` syntax allowance were introduced.


=
rpuntaie wrote:
=

Allow initial comma
===

Final comma works:

    t = (
 1,
 2,
    )
    x = [
 1,
 2,
    ]
    y = {
 1,
 2,
    }
    z = {
 1:11,
 2:22,
    }
    def fun(
  a,
  b,
 ):
  pass

Initial comma does not work:

    t = (
 , 1
 , 2
    )
    x = [
 , 1
 , 2
    ]
    y = {
 , 1
 , 2
 }
    z = {
 , 1:11
 , 2:22
 }
    def fun(
 , a
 , b
 ):
  pass


To make the syntax symmetric in this regard\
gives more freedom to format the code.

I occasionally found the restriction an unnecessary nuisance.

Before writing a PEP, I would like to discuss,

-   whether something like that has been proposed already?
-   what counter-arguments there could be?

=
pxeger wrote:
=

This is not the appropriate place to propose language changes.
Try the 
[python-ideas](https://mail.python.org/mailman3/lists/python-ideas.python.org/ 
)

mailing list. However, I don't think you'll get anyone to agree.

What kind of code style are you using where you want to put commas at
the start of the line? That is totally non-standard
(see [PEP 8](https://www.python.org/dev/peps/pep-0008 
)), ugly, and confusing.


Arbitrary symmetry is not a good reason for changing the language. We
don't have a `tnirp` function just for the sake of symmetry with
`print` because it would be pointless and add extra complication


=
rpuntaie wrote:
=

I surely agree, that not ignoring the sequence is essential. Else one
would loose identifier space and thus information. I would never have
the idea to make all permutations of `p.r.i.n.t` point to the same
function. Therefore you just made a bad example.

But the comma is just a separator. Why did they allow to have the
comma before a closing bracket/parenthesis/brace? Because of symmetry
between lines, is my guess.

Occasionally one sees many spaces just the have the final comma
aligned vertically. That could be avoided by placing the comma at the
beginning.

I personally also have a macro in the editor that evaluates a line in
the parameter list, but drops an initial comma before doing that.
Therefore this is my preferred formatting.

I don't think that [PEP](https://www.python.org/dev/peps/pep-0008 
)

is wrong. I just don't want to be restricted by unnecessary rules.
Rules need to have a reason beyond someone dictating them. If that is
the case, I follow them, because I see the reason, but not because
someone dictates them.

I'll go to
[Python Ide 
as](https://mail.python.org/mailman3/lists/python-ideas.python.org/ 
),

then. Thanks.
___
Python-ideas mailing list -- python-ideas@python.org 

[Python-ideas] Re: allow initial comma

[Paul Bryan]

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?

On Fri, 2021-03-12 at 10:34 +, roland.puntaier--- via Python-ideas
wrote:
> I had posted this as https://github.com/python/peps/issues/1867
> The discussion so far is below.
> 
> Please make some arguments.
> 
> The major point to me is, that the symmetry is broken,
> which leads to extra editing actions, like removing the comma in the
> first line.
> I guess, this was the reason to allow the comma after the last
> line/entry: `[1,2,]`.
> ``[,1,2]`` should also be allowed, too.
> 
> The best argument is one that says: less or more effort in this or
> that situation.
> For example, with `[1,2,]`, in line-wise formatting,
> one can do without special action at the last line (removing the
> comma there).
> 
> All code from previous versions of Python would still work
> after a `[,1,2]` syntax allowance were introduced.
> 
> 
> =
> 
> rpuntaie wrote:
> =
> 
> 
> Allow initial comma
> ===
> 
> Final comma works:
> 
>     t = (
>  1,
>  2,
>     )
>     x = [
>  1,
>  2,
>     ]
>     y = {
>  1,
>  2,
>     }
>     z = {
>  1:11,
>  2:22,
>     }
>     def fun(
>   a,
>   b,
>  ):
>   pass
> 
> Initial comma does not work:
> 
>     t = (
>  , 1
>  , 2
>     )
>     x = [
>  , 1
>  , 2
>     ]
>     y = {
>  , 1
>  , 2
>  }
>     z = {
>  , 1:11
>  , 2:22
>  }
>     def fun(
>  , a
>  , b
>  ):
>   pass
> 
> 
> To make the syntax symmetric in this regard\
> gives more freedom to format the code.
> 
> I occasionally found the restriction an unnecessary nuisance.
> 
> Before writing a PEP, I would like to discuss,
> 
> -   whether something like that has been proposed already?
> -   what counter-arguments there could be?
> 
> =
> 
> pxeger wrote:
> =
> 
> 
> This is not the appropriate place to propose language changes.
> Try the [python-
> ideas](https://mail.python.org/mailman3/lists/python-ideas.python.org/
> )
> mailing list. However, I don't think you'll get anyone to agree.
> 
> What kind of code style are you using where you want to put commas at
> the start of the line? That is totally non-standard
> (see [PEP 8](https://www.python.org/dev/peps/pep-0008)), ugly, and
> confusing.
> 
> Arbitrary symmetry is not a good reason for changing the language. We
> don't have a `tnirp` function just for the sake of symmetry with
> `print` because it would be pointless and add extra complication
> 
> 
> =
> 
> rpuntaie wrote:
> =
> 
> 
> I surely agree, that not ignoring the sequence is essential. Else one
> would loose identifier space and thus information. I would never have
> the idea to make all permutations of `p.r.i.n.t` point to the same
> function. Therefore you just made a bad example.
> 
> But the comma is just a separator. Why did they allow to have the
> comma before a closing bracket/parenthesis/brace? Because of symmetry
> between lines, is my guess.
> 
> Occasionally one sees many spaces just the have the final comma
> aligned vertically. That could be avoided by placing the comma at the
> beginning.
> 
> I personally also have a macro in the editor that evaluates a line in
> the parameter list, but drops an initial comma before doing that.
> Therefore this is my preferred formatting.
> 
> I don't think that [PEP](https://www.python.org/dev/peps/pep-0008)
> is wrong. I just don't want to be restricted by unnecessary rules.
> Rules need to have a reason beyond someone dictating them. If that is
> the case, I follow them, because I see the reason, but not because
> someone dictates them.
> 
> I'll go to
> [Python Ide
> as](https://mail.python.org/mailman3/lists/python-ideas.python.org/),
> then. Thanks.
> ___
> 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/E3HYA7AWLHTD3MCWVBRH7AT3GLGXFUOG/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas 

[Python-ideas] Re: allow initial comma

[Paul Moore]

On Fri, 12 Mar 2021 at 13:22, roland.puntaier--- via Python-ideas
 wrote:
>
> I had posted this as https://github.com/python/peps/issues/1867
> The discussion so far is below.
>
> Please make some arguments.
>
> The major point to me is, that the symmetry is broken,
> which leads to extra editing actions, like removing the comma in the first 
> line.
> I guess, this was the reason to allow the comma after the last line/entry: 
> `[1,2,]`.
> ``[,1,2]`` should also be allowed, too.

This layout style is not something I've ever seen used in "real life",
and I don't think it's something that should be encouraged, much less
added to the language.

> But the comma is just a separator. Why did they allow to have the
> comma before a closing bracket/parenthesis/brace? Because of symmetry
> between lines, is my guess.

More likely because there are two common schools of thought - lists
have punctuation *separating* items, and lists have punctuation
*terminating* items. I don't even know a commonly used term for the
idea of having something *before* each item. So I think you need to
find examples of other languages that support this style if you want
to advocate for it, otherwise you'll need to demonstrate that it's
important enough for Python to go against the norm here.

> I personally also have a macro in the editor that evaluates a line in
> the parameter list, but drops an initial comma before doing that.
> Therefore this is my preferred formatting.

But (1) "it's my preference" isn't sufficient to change the language,
and (2) why not change your macro to remove a *trailing* comma
instead?

Overall, I don't think this is a good idea. -1 from me.

Paul
___
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/5RENNY6WP5VSWKHAIVTWU4R3VA4BGWIC/
Code of Conduct: http://python.org/psf/codeofconduct/