Currently, a snippet like
[i+1for i in range(10)]
will raise SyntaxWarning: invalid decimal literal, due to the 1for. This is to warn against deprecation (it was changed from a DeprecationWarning, but nevermind that choice for now) of the syntax due to parser inconsistencies documented in this GH issue.
Said issue led quickly to a PR from @storchaka to implement the mentioned warnings. It seems there was initial hope to turn these warnings to errors as soon as 3.12, though this has been (thankfully) put off (though now it’s unclear when it is happening).
Fundamentally, this is a good warning to have. Examples like the above code are ambiguous (especially when involving hex and octal literals) and almost always a mistake by the programmer. I like that it’s a warning.
What I don’t like is the eventual plan to turn them into full-fledged errors, at least without any further regard to the points I’m about to list.
1. There are some selfish motivations for being against these errors: code golfing. A few people have mentioned the utility of these whitespace savings in code golf, where the goal is to accomplish some task in as few characters of source code as possible. No real regard was given to these commenters; not that they should inherently hold such sway, but direct responses would have been nice.
At any rate, errors would break thousands of solutions on sites like the Code Golf Stack Exchange and code.golf; the latter of these is also “live” competition, in the sense that no-longer-passing solutions to holes are removed, so we would expect sweeping deletions. Either that, or a “break” in Python as a language on these sites, <3.x and >=3.x, which seems a bit silly. The only time a Python version has caused suck a break was 2 → 3, which makes perfect sense given its scope. Every version since has only helped golfers, e.g. 3.8 with the walrus operator :=.
2. More generally, the depth of discussion surrounding this change has been a bit disappointing. @storchaka’s PR was written and merged rather quickly following the simple collection of examples of relevant parser bugs, which is admirable, but also a tad concerning. I need only link the final comment in a still-open GH issue opposing the warnings outright. I don’t completely agree with exander77’s sentiments, but I do agree with the comment. @mdickinson recommended in that thread that responses move to the ideas forum, so here were are.
I’m somewhat reminded of the @classmethod @property debacle, wherein “class properties” got added then removed within 2 versions thanks to some resulting issues elsewhere in the codebase. For as slowly and carefully Python development does rightly move, I’m rather annoyed by these instances of hasty decision-making.
In all, I don’t think its unreasonable to claim that, while fixing the parser and warning programmers of the upcoming changes needed to do so is great, the roadmap for making it all happen is poor. I am peeved by the lack of addressal of the concerns raised by exander77, not because they specifically have not received a response (the issue is from January), but because the quotes they collected did not receive adequate responses at the time (over 3 years ago at this point).
Of course, asking to retract progress entirely would be fruitless and just plain dumb, so my actual “idea” boils down to just one request: an interpreter flag or environment variable. Let us use the old parser, bugs and all. As far as I can tell, it’d be pretty inexpensive.
It’s either that, let “backwards compatibility be damned” and kill all the old golfs (that’s a rather upsetting quote to hear from Guido to be honest), or some secret third thing, which I’m happy to explore.
reactions and nothing more, which doesn’t leave a great taste in my mouth). exander’s collected comments were similarly unaddressed, though he did not move discussion here as suggested.