No, it doesn’t. Please don’t fall into the trap of thinking “it’s okay to break code as long as it was written more than X years ago”, especially not if X < 10.
I periodically come across old code, and depending on the language and ecosystem, it may work perfectly, or at least adequately. One of my current ongoing projects is cleaning up some positively ancient JavaScript code which is still completely functional, but the world has moved on (for instance, a messy pile of code to give you five choices of font size, but which breaks if you use your browser’s zoom feature). And, not quite so ancient, but still quite old - this module works just fine on modern Python versions, and successfully decodes the data dump from a Wordpress site. That’s eleven year old code. When that code was written, Python 3.3 was current.
Would you consider that perfectly valid and useful syntax should be allowed to be deprecated in Python 3.4 and removed anywhere before Python 3.12? If so, you would be telling me (and my client) that we need to rewrite someone else’s code, just because old code is bad code.
Breaking people’s code is a BIG DEAL and a lot of people seem to have insufficient respect for this.
Oh, and - if you say “well okay then, we can deprecate it now and not actually make it an error for X years”, you not only break people’s code eventually, you also mean that your change won’t have any real benefit for X years plus however long it takes for people to upgrade to the newest version. So a high value for X isn’t a solution either. (Deprecation warnings are often ignored, and will be of minimal value to novice programmers.)
I heard this argument during a debate on python-ideas many years ago, then it was about making time(0) truthy. I’m pretty sure that change fixed a lot of broken code. I am very glad that the change was made though!
The same argument is the argument against python 3. Again I am very happy that decision was taken.
Breaking code is a big deal. Absolutely. But breaking code that is broken is an improvement. Letting errors slip by silently to cause havoc down stream is very bad.
Yes. I’m not saying that breaking code should never be done, but it is a very very big deal. Making datetime.time(0) true would break a small amount of code and fix a larger amount of code. In order to make the argument that trailing commas are similar, you have to show that it is almost never correct when written in this way, that it is frequently incorrect (bearing in mind that it could easily be neither correct nor incorrect), and that the breakage is justified.
Years of deprecation is NOT a solution. There must be sufficient justification even without that.
Breaking broken code is sometimes an improvement, sometimes not. Breaking code that MIGHT be broken is a lot harder to justify. I’m completely unconvinced that it’s worthwhile in this case.
Creating a one tuple, then discarding it, can never be useful and is unlikely to be intended.
So, I think we probably should emit a warning in this case.
True, but it’s also not going to be a problem. I count that sort of thing among the “not correct, not incorrect” cases. To be quite honest, the peephole optimizer could probably just silently remove that, as it wouldn’t have any effect (BUILD_TUPLE 1 followed by POP_TOP could become simply POP_TOP).
All the situations where the code could be wrong, it could also be right.
IMO, this is a task for editors to warn about. Next would be linters, yes. Warnings or even exceptions don’t seem right, since this is valid Python code.
FWIW: I don’t think beginners will have to deal with 1-tuples a lot and if whoever teaches them, doesn’t even mention that you can write tuples without parens, it’s rather unlikely they’ll get into this situation often
I use it in real code on purpose quite regularly. And no, I don’t want to add parentheses. I strongly disagree with your willingness to break working code written by people who understand the syntax and use it correctly, if I’m honest.
Fine. The rules you choose to apply in your code review are entirely your concern. But that doesn’t give you the right to impose those rules on everyone.
Claiming that other people’s code is “broken” when it works, just because it uses a construct that you don’t like, is pretty arrogant… I suggest you tone down your rhetoric - you’re not helping your argument by this sort of claim.
I was talking about situations where beginners get a 1-tuple, don’t know why, and “fix it” by adding [0] in one or more places. I hope you and I can agree that that code is in fact broken, even though it technically works.
I was absolutely not saying that on purpose cases of creating a 1-tuple with the smallest syntax is broken. That would indeed be even more arrogant than I am at my most arrogant
I do see it fairly regularly though I don’t think it’s because they’re trying to use that feature (in fact most have no idea what I’m talking about when I explain it!), but they just happen to have a stray comma. I can only hypothesize how it got there.
For my I get it a lot when moving something out of a dict or list:
foo = dict(
bar=4,
)
to the item by itself:
bar=4,
My examples have more code per line so it’s harder to spot the trailing comma.
I’ve been writing Python code for a few years and feel still close to the beginner I was. I can only feel and express sympathy for this request. I got bitten by this many times and still do occasionally. Usually (I would hope!) that doesn’t make it into merged code, yet it surely goes into my way.
Most things are subjective of course. However when I see this
x = 1,
I know it’s a tuple, yet, I cannot help but feel that this is unfinished matter. It is a comma at the end of a book chapter: “Surely that must be a typo, right? Or what if there is more and it’s missing? Or what if there was more that has been removed and the comma not replaced with a dot?” It’s asking more questions than giving answers. It’s a challenge for the untrained, or simply tired, eyes. It’s defying English, or French in my case.
While
x = (1,)
is a much clearer and simpler view of the world, it’s a closed sentence, I can move on to the next chapter without “What if?”.
Stylistically, I prefer adding parentheses around one-tuples, as it makes them obvious. I’ll only ever omit the parentheses around tuple literals when unpacking return values and in return statements, both of which one-tuples don’t make sense.
That is incorrect. Many newcomers, possibly a large majority, use IDEs like PyCharm which default to running a linter – especially on Windows. If you look at the posts here on Discourse, you will often see beginners asking for help with linter warnings.
Python the language rarely prohibits otherwise legal syntax merely because of style concerns.
Personally, seeing single-space indents with no spaces around operators and unneccessary brackets around if conditions make me want to turn the computer off and become a hermit living at the top of the nearest mountain:
if (something):
result=spam+eggs
But I wouldn’t want Python to make that a syntax error, or even a syntax warning. Broadly speaking, the language should not make a special case for legal syntax just because some people don’t like it.
Another factor that we should consider is machine-generated code. Not all code is written by humans directly. Some code is generated programmatically. Making 1-tuples a special case that requires parentheses while other non-empty tuples do not is a complication that makes code generators harder to write.
It’s not though. That’s a big point. The location of the problem and the crash can be very far from each other and the crash message is obscure. Especially for beginners who might not even know the word “tuple”!
I don’t think it’s because they’re trying to use that feature (in fact most have no idea what I’m talking about when I explain it!), but they just happen to have a stray comma. I can only hypothesize how it got there.