I like the idea of deprecating bare except: (and eventually, after a long time, disallowing it).
In my personal experience, more than 90% of the time when I see a bare except, it’s not being re-raised and catching Exception would have been appropriate. I see it as a bad default. I expect that programmers would default to writing except Exception over except BaseException if the bare except gave a warning or an error.
Linters catch this problem, but a lot of Python programmers don’t use linters.
I’ve been using python as my main programming language both for work and hobby use for over 17 years, and I came here to say that this PEP is a bad idea in my book. Causing a lot of headache for practically everyone, for little to no benefit. All of that, over a nitpick of an issue.
Let this be handled by ruff or other linters, that’s where it belongs.
-1 on the warning. Warnings can already a pain to track down when they arise deep in the dependency tree. I don’t relish the thought of getting a SyntaxWarning for importing a module that uses a bare except, possibly in a function I never even hit.
Anyway, I’m -1 on the PEP, as well. The gains are minimal, the ability to be quick and dirty in scripts is valuable, and linters cover this just fine.
While I do see many projects relying on bare exceptions I do agree that a change might be explored and a larger delay would be a good thing. I would almost want the delay to be delayed more than two years to take advantage of the speed optimizations (which large companies or projects could justify the changes) so I agree five years would be a better compromise at least.
This phrase gets thrown around a lot, but nothing in this proposal is preventing except BaseException, it’s requiring that someone be clear that that’s their intent and that it isn’t uninformed use. Part of consent involves being informed of what you are consenting to.
I thought this had been fixed already keeping the builtins alive until after these are handled. If not, that can be addressed. (I remember there being a time when this, and other builtins weren’t safe to use, but I’d have to actively search for it, I’m pretty sure this is a historical issue an no longer present)
To strengthen this point: The most common situation where “consenting adults” gets mentioned is with regard to private variables and the fact that in python you can always access them since they just start with an underscore: You just have to explicitly opt into using them. It is not the case that “private” variables look the exact same and people are expected to read the docs to figure out what is private and what not.
I’m not sure a __future__ would help much here. Having a future import is helpful when some users want to opt in to the new feature early (e.g., annotations) or when you want to be able to write the same code across Python versions (e.g., division and print_statement). But for this PEP, a future import doesn’t really add much relative to a linter that disallows bare except. Such a linter can be run over a large codebase much more easily, and changes can be applied even if you still want to support versions of Python earlier than 3.14.
Searching on github for “except:” and limiting to python (Code search results · GitHub ) returns 3.6m files; that’s a fairly naïve search and haven’t done any filtering.
The fundamental argument here of “shouldn’t those lines be using a more explicit exception handler” is of course valid, but this change would change the behavior of all of those files.
I don’t know why anyone wants this proposal. It is just wanton breakage for no real gain.
It would be nice if Python placed more value in keeping existing code working (not just CPython but all the Python packages as well). This kind of proposal should be dead in the water but people apparently accept breaking compatibility to the extent that it can be done frivolously.
Edit: I didn’t mean to reply to Mike specifically, I think I just clicked the reply button…
Of course I can do this little bit of extra work. But I wouldn’t “opt in”, you would be forcing me to do it. I believe the marginal benefit of this change versus leaving it to the IDE or linter is not worth the disruption. BTW, I checked my code base and cannot find a single raw except clause maybe because Pycharm does a good job of nagging me about it. And if someone makes a habit of ignoring IDE warnings, they have bigger problems than this.
I don’t view it that way, nor do many other people.
I view it as increasing the ability to be confident that we are reviewing code properly and that the author’s intent is clearly available to those reviewing the code. Code is frequently outliving the original author (or at least their availability) at this point.
I also share the concerns about breaking, which is why I argued it should be a longer timeline with high visibility.
I’m aware there are many “one off scripts” out there, that those scripts would survive another 5 years and still be in use would indicate that it is not just a one off script, and that a one time change at some point within those five years to go “yep, that was actually my intent, to even catch control flow exceptions”, should not be a high burden for in-use scripts. That is a change they can make today without breaking existing use.
See discussion on hackernews here. PEP 760: No more bare excepts | Hacker News
This is a massive backward incompatibility problem. I propose having an interpreter flag to allow bare excepts, so the pain is reduced.
I believe the argument against suppressing KeyboardInterrupt, SystemExit, and other exceptions not derived from Exception doesn’t hold. It’s more beneficial for users to learn how to handle these specific cases correctly, even if it requires some initial difficulty.
Following up on this, this hasn’t been the case since 2014 (3.4, a decade ago) and does not impact any currently supported python version : cpython: 5d3b9862f1bc
