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.
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".
- 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 `[,`.
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 :-).
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. Steve