
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.

On Fri, 12 Mar 2021 at 13:22, roland.puntaier--- via Python-ideas <python-ideas@python.org> 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. 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.
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

Hi, On Fri, 12 Mar 2021 at 15:12, Paul Moore <p.f.moore@gmail.com> wrote:
If Roland wants to prepend each item of his list, he can always write
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.

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 +0000, roland.puntaier--- via Python-ideas 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. I don't see a reason to make that odd style easier. --Ned. On 3/12/21 9:27 AM, Paul Bryan wrote:

On Fri, 12 Mar 2021 at 16:06, Ned Batchelder <ned@nedbatchelder.com> 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

On 2021-03-12 at 11:02:50 -0500, Ned Batchelder <ned@nedbatchelder.com> wrote:
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.

On 3/12/2021 3:37 PM, Greg Ewing wrote:
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

This is a definite tangent. Trailing commas are great for reducing git diffs, not making errors when moving things around (missing commas, which e.g. in strings causes concatenation) but I have often wondered whether the same could be extended to (some?) logical or arithmetic operators, in particular: Currently one has to write a logical expression as (using Django Q objects): ( Q(user=user) | Q(is_deleted=True) ) and then removing/adding clauses is difficult, whereas if "trailing operators" where allowed, there would be no such issue: ( Q(user=user) | Q(is_deleted=True) | ) Just like with trailing commas, the "additional" operator would be ignored. I guess (technically) it won't have to match the previous operator, it could just be any operator with no argument after it. Unlike with trailing comma, I think an operator on its own would not be allowed (e.g. "(|)" or "|") as it's meaning-as-intended will be context dependent (e.g. in this example, the correct answer is a Q() object). I am happy to flesh this out more, but as this discussion was ongoing, I thought I would throw it out here and see what people think? Are there potential problems with this e.g. with parsing it? On Fri, 12 Mar 2021 at 14:28, Paul Bryan <pbryan@anode.ca> wrote:

On Fri 21Mar12 14:27, Paul Bryan wrote:
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`.

Hi Roland You're correct. Sometimes in Python there's no symmetry between beginning and end. This is I think because we read Python code top-down rather than bottom-up. And as it happens, the compiler and other data processing tools usually start at the beginning of the file. (1) Here's something you might not have thought of >>> (1) 1 >>> (1,) (1,) You're asking for >>> (,1) (1,) (2)Now for some asides. The https://en.wikipedia.org/wiki/Arrow_of_time says that the arrow of time
(3) The Elm language uses leading commas on the second and subsequent items on a list. Here's some Elm code that's gone through the elm-format command. (It's analogous to Python's black.) fahrenheit = { freezing_point = 32 , boiling_point = 212 } freezing_point = 32 boiling_point = 212 data = [ [ [ 1, 2, 3 ], [ 4, 6, 6 ] ] , [ 10, 20, 30, 40, 50 ] , [ 10 , 20 , 30 , 40 , 50 ] ] (4) Finally, here is an Elm bug that I happened to raise a few hours earlier. It's: Malformed record modify `{ key | }` creates EXTRA COMMA error https://github.com/elm/compiler/issues/2181 with best wishes Jonathan

On Mon 21Mar15 12:30, Jonathan Fine wrote:
This side effect is logically OK, I think. Function parameters are a tuple plus possibly a dict. And if we have x = (,1) x = ,1 it is also a tuple. They are equivalent to the current x = (1,) x = 1,
For me time is a tagging of changes. Without changes no time. Independent changes, independent tags, independent times. Changes are on states. Here the state could be the lines with starting comma. The change takes less time, if I don't need to change the comma, when changing the order of the lines. The time/tagging of the parser is a completely different time.
I don't know elm, so I cannot comment.
This elm bug does not seem to be related to the topic here.

On Mon, Mar 15, 2021, 06:15 Roland Puntaier via Python-ideas < python-ideas@python.org> wrote:
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.

Roland Puntaier via Python-ideas writes:
My concern is more that someone's aesthetic concern has impact
But that has always been true of programming languages, most obviously so in Intercal and Brainf!ck :-). And Python is quite opinionated, in fact, about stylistic concerns like indentation and use of keywords rather than symbols for logical operators.
on the practical needs of many.
What needs are those? What new idea (or old idea that currently requires more verbose expression) does the leading comma express? The trailing comma expresses the idea that "this is complete for now, but more elements are likely to be placed here in the future". This idea is not part of the Python language, but to humans it's a useful statement *about* a Python program. As far as I can see, that's what is expressed by the proposed leading comma as well.
Else, if a reasonable interpretation is possible, do it.
This is considered an anti-pattern by most developers of Python, I believe. The rule is not "if you can interpret it, assign that meaning". It's "if you want to do it, find a way to express it".
This is a purely aesthetic statement. It's a matter of style in designing a programming language, rather than in coding a program, but it's style nonetheless.
- Can `x=[,1,2]` be misinterpreted? As `,]` has found a reasonable interpretation, so can `[,`.
But there's no reason I can see why it has to have the same interpretation as ",]". It seems to me possible that a *different* interpretation may be discovered, and that would be an argument *against* allowing it: why waste a succinct construct on something you can already do equally succinctly? If you have a use case where adding new elements at the front of a list is clearly preferable to adding at the end and would benefit from the leading comma, you should present that. I do have a few cases where I add at the front by design (they're all in Emacs Lisp, though). But my own experience is that I never make the mistake of omitting the trailing comma on the rare occasion I prepend a new item to a Python sequence display, whereas I frequently omit the trailing comma on the preceding line when adding at the end. For me these situations are not symmetric, the trailing comma is a win but the leading one is a no-op (and I personally would avoid it, as I find it aesthetically displeasing :-).
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. Steve

On Mon 21Mar15 22:24, Stephen J. Turnbull wrote:
Python is very much also used as a command line language (IPython, Jupyter, ...). This little added syntactic flexibility does not disrupt the basic pythonic style, but it can avoid error fix cycles in command line or py file, that were due to some occasional copy/paste/attention oops.
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
But `,]` would be against that, too. My proposal is just the symmetric `[,`.
Yes.
Same applies to `,]`.
"preferable" would be up to the situation/person.
Not all people care about aesthetics. I'm one of them. It is just in some situations, I prefer to put the comma in front, - due to my editor macro and - I also can see it there and be sure not to have forgotten it. The ends do not all end at the same column and so the eye needs to find the end first to check the comma is there.
This is not my proposal, but I would welcome it.

Thank you Roland, for that idea! On Tue, Mar 16, 2021 at 01:52:48PM +0100, Roland Puntaier via Python-ideas wrote:
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.
Nice. Also useful for huge dict/mappings definitions.
I also. H.

On Mon, 2021-03-15 at 11:13 +0100, Roland Puntaier via Python-ideas wrote:
If implemented, such a proposal would in fact require a change to the language specification.
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. Paul

On Mon 21Mar15 15:18, Paul Bryan wrote:
Yes. What I meant is, that it is minor, equivalent to the `,]` change.
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.

On 3/16/21 8:22 AM, Roland Puntaier via Python-ideas wrote:
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.

On 3/16/21 8:22 AM, Roland Puntaier via Python-ideas wrote:
My thought is that there is a line in the Zen
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

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:
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>

On Tue, Mar 16, 2021 at 08:28:05AM -0700, Guido van Rossum wrote:
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.

On Fri, 12 Mar 2021 at 13:22, roland.puntaier--- via Python-ideas <python-ideas@python.org> 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. 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.
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

Hi, On Fri, 12 Mar 2021 at 15:12, Paul Moore <p.f.moore@gmail.com> wrote:
If Roland wants to prepend each item of his list, he can always write
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.

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 +0000, roland.puntaier--- via Python-ideas 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. I don't see a reason to make that odd style easier. --Ned. On 3/12/21 9:27 AM, Paul Bryan wrote:

On Fri, 12 Mar 2021 at 16:06, Ned Batchelder <ned@nedbatchelder.com> 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

On 2021-03-12 at 11:02:50 -0500, Ned Batchelder <ned@nedbatchelder.com> wrote:
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.

On 3/12/2021 3:37 PM, Greg Ewing wrote:
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

This is a definite tangent. Trailing commas are great for reducing git diffs, not making errors when moving things around (missing commas, which e.g. in strings causes concatenation) but I have often wondered whether the same could be extended to (some?) logical or arithmetic operators, in particular: Currently one has to write a logical expression as (using Django Q objects): ( Q(user=user) | Q(is_deleted=True) ) and then removing/adding clauses is difficult, whereas if "trailing operators" where allowed, there would be no such issue: ( Q(user=user) | Q(is_deleted=True) | ) Just like with trailing commas, the "additional" operator would be ignored. I guess (technically) it won't have to match the previous operator, it could just be any operator with no argument after it. Unlike with trailing comma, I think an operator on its own would not be allowed (e.g. "(|)" or "|") as it's meaning-as-intended will be context dependent (e.g. in this example, the correct answer is a Q() object). I am happy to flesh this out more, but as this discussion was ongoing, I thought I would throw it out here and see what people think? Are there potential problems with this e.g. with parsing it? On Fri, 12 Mar 2021 at 14:28, Paul Bryan <pbryan@anode.ca> wrote:

On Fri 21Mar12 14:27, Paul Bryan wrote:
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`.

Hi Roland You're correct. Sometimes in Python there's no symmetry between beginning and end. This is I think because we read Python code top-down rather than bottom-up. And as it happens, the compiler and other data processing tools usually start at the beginning of the file. (1) Here's something you might not have thought of >>> (1) 1 >>> (1,) (1,) You're asking for >>> (,1) (1,) (2)Now for some asides. The https://en.wikipedia.org/wiki/Arrow_of_time says that the arrow of time
(3) The Elm language uses leading commas on the second and subsequent items on a list. Here's some Elm code that's gone through the elm-format command. (It's analogous to Python's black.) fahrenheit = { freezing_point = 32 , boiling_point = 212 } freezing_point = 32 boiling_point = 212 data = [ [ [ 1, 2, 3 ], [ 4, 6, 6 ] ] , [ 10, 20, 30, 40, 50 ] , [ 10 , 20 , 30 , 40 , 50 ] ] (4) Finally, here is an Elm bug that I happened to raise a few hours earlier. It's: Malformed record modify `{ key | }` creates EXTRA COMMA error https://github.com/elm/compiler/issues/2181 with best wishes Jonathan

On Mon 21Mar15 12:30, Jonathan Fine wrote:
This side effect is logically OK, I think. Function parameters are a tuple plus possibly a dict. And if we have x = (,1) x = ,1 it is also a tuple. They are equivalent to the current x = (1,) x = 1,
For me time is a tagging of changes. Without changes no time. Independent changes, independent tags, independent times. Changes are on states. Here the state could be the lines with starting comma. The change takes less time, if I don't need to change the comma, when changing the order of the lines. The time/tagging of the parser is a completely different time.
I don't know elm, so I cannot comment.
This elm bug does not seem to be related to the topic here.

On Mon, Mar 15, 2021, 06:15 Roland Puntaier via Python-ideas < python-ideas@python.org> wrote:
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.

Roland Puntaier via Python-ideas writes:
My concern is more that someone's aesthetic concern has impact
But that has always been true of programming languages, most obviously so in Intercal and Brainf!ck :-). And Python is quite opinionated, in fact, about stylistic concerns like indentation and use of keywords rather than symbols for logical operators.
on the practical needs of many.
What needs are those? What new idea (or old idea that currently requires more verbose expression) does the leading comma express? The trailing comma expresses the idea that "this is complete for now, but more elements are likely to be placed here in the future". This idea is not part of the Python language, but to humans it's a useful statement *about* a Python program. As far as I can see, that's what is expressed by the proposed leading comma as well.
Else, if a reasonable interpretation is possible, do it.
This is considered an anti-pattern by most developers of Python, I believe. The rule is not "if you can interpret it, assign that meaning". It's "if you want to do it, find a way to express it".
This is a purely aesthetic statement. It's a matter of style in designing a programming language, rather than in coding a program, but it's style nonetheless.
- Can `x=[,1,2]` be misinterpreted? As `,]` has found a reasonable interpretation, so can `[,`.
But there's no reason I can see why it has to have the same interpretation as ",]". It seems to me possible that a *different* interpretation may be discovered, and that would be an argument *against* allowing it: why waste a succinct construct on something you can already do equally succinctly? If you have a use case where adding new elements at the front of a list is clearly preferable to adding at the end and would benefit from the leading comma, you should present that. I do have a few cases where I add at the front by design (they're all in Emacs Lisp, though). But my own experience is that I never make the mistake of omitting the trailing comma on the rare occasion I prepend a new item to a Python sequence display, whereas I frequently omit the trailing comma on the preceding line when adding at the end. For me these situations are not symmetric, the trailing comma is a win but the leading one is a no-op (and I personally would avoid it, as I find it aesthetically displeasing :-).
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. Steve

On Mon 21Mar15 22:24, Stephen J. Turnbull wrote:
Python is very much also used as a command line language (IPython, Jupyter, ...). This little added syntactic flexibility does not disrupt the basic pythonic style, but it can avoid error fix cycles in command line or py file, that were due to some occasional copy/paste/attention oops.
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
But `,]` would be against that, too. My proposal is just the symmetric `[,`.
Yes.
Same applies to `,]`.
"preferable" would be up to the situation/person.
Not all people care about aesthetics. I'm one of them. It is just in some situations, I prefer to put the comma in front, - due to my editor macro and - I also can see it there and be sure not to have forgotten it. The ends do not all end at the same column and so the eye needs to find the end first to check the comma is there.
This is not my proposal, but I would welcome it.

Thank you Roland, for that idea! On Tue, Mar 16, 2021 at 01:52:48PM +0100, Roland Puntaier via Python-ideas wrote:
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.
Nice. Also useful for huge dict/mappings definitions.
I also. H.

On Mon, 2021-03-15 at 11:13 +0100, Roland Puntaier via Python-ideas wrote:
If implemented, such a proposal would in fact require a change to the language specification.
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. Paul

On Mon 21Mar15 15:18, Paul Bryan wrote:
Yes. What I meant is, that it is minor, equivalent to the `,]` change.
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.

On 3/16/21 8:22 AM, Roland Puntaier via Python-ideas wrote:
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.

On 3/16/21 8:22 AM, Roland Puntaier via Python-ideas wrote:
My thought is that there is a line in the Zen
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

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:
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>

On Tue, Mar 16, 2021 at 08:28:05AM -0700, Guido van Rossum wrote:
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.
participants (19)
-
2QdxY4RzWzUUiLuE@potatochowder.com
-
Chris Angelico
-
Eric V. Smith
-
Ethan Furman
-
Gerrit Holl
-
Greg Ewing
-
Guido van Rossum
-
Hans Ginzel
-
Henk-Jaap Wagenaar
-
Jonathan Fine
-
Ned Batchelder
-
Paul Bryan
-
Paul Moore
-
Richard Damon
-
Richard Damon
-
Roland Puntaier
-
roland.puntaier@chello.at
-
Stephen J. Turnbull
-
Todd