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.
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?
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.
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.
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
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".
But `,]` would be against that, too. My proposal is just the symmetric `[,`.
- 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.
Yes.
- 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?
Same applies to `,]`.
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).
"preferable" would be up to the situation/person.
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 :-).
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.
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.