15 ms·

PEP 760: No more bare excepts

• __turbobrew__ 2y ago
  Continuing Pythons tradition of breaking perfectly functional code.
• sph 2y ago
  This would be a backward-incompatible change, no? In other languages, such a change would only be possible with a major version bump, though I imagine that because of the Python 3 collective trauma, the language designers now are OK with breaking older code without calling it Python 4. Anything goes, as long as it's called Python 3. (Python lost me in the 2->3 migration and I haven't used it in a decade, so correct me if I'm wrong)
  • letmeinhere 2y ago
    Python doesn't use semantic versioning. The number after the first period is a major (annual) release and can and does contain breaking changes (though so far never on the scale of the 2->3 upgrade). We may never see a 4.0 because of the scar tissue, but the language continues to evolve.
    • sph 2y ago
      Linux: let's bump the major version just because Python: for the love of God [1] don't touch the version I wonder if the scar tissue will ever heal and we'll see a Python 4 in two decades. 1: https://www.youtube.com/watch?v=asUyK6JWt9U https://www.youtube.com/watch?v=asUyK6JWt9U
      • hnlmorg 2y ago
        Probably not before a Perl 6
      • sgarland 2y ago
        K8s: the major version will never change, so instead we’ll introduce breaking changes with minor versions.
    • infamia 2y ago
      > We may never see a 4.0 because of the scar tissue, but the language continues to evolve. They should do the opposite really. If it hurts, do it more often and get better at it. A perfect time would be when Python gets some nice JIT performance improvements which everyone will probably like.
  • mananaysiempre 2y ago
    I don’t think there have been significant backwards-incompatible changes in Python 3 the language. There have been some, e.g. async and await were first introduced as soft keywords and then switched to being actual ones. But that’s not all that different from the treatment of yield in Python 2. (Recent stdlib changes have been much more destructive, but I’m assuming that, like in the original thread, we’re drawing a distinction between those and changes to the actual language.) Full disclosure, I welcomed Python 3, because for me that was the first time (since 2.4 on Windows XP) that I could count on my programs not randomly shitting their pants upon encountering Cyrillic in files or filenames, which for a native speaker of Russian you can imagine is quite important. (The csv stdlib module in Python 2 did that, IIRC. Perhaps I was holding it wrong, but experience shows that absolutely everybody did.)
    • echoangle 2y ago
      I think basically every new python version removes some standard libs and marks new ones as deprecated (at least 3.13 did), that’s potentially breaking.
      • zahlman 2y ago
        The bytecode format changes, too, as does the C ABI (although they're making improvements on the latter front - there's supposed to be a more stable subset now). But more recently, they committed to a proper scheduling procedure for standard library deprecations and removals.
      • mananaysiempre 2y ago
        Incompatible library changes do happen, but the 3.11–13 removals, or more specifically PEP 594[1] removals, were abnormally destructive. [1] https://peps.python.org/pep-0594/ https://peps.python.org/pep-0594/
    • wren6991 2y ago
      One that bit me was the change to StopIteration propagating through chained generators, following PEP 479. Nothing huge, but I had to patch some previously working code to accommodate the new language release.
  • pdonis 2y ago
    > This would be a backward-incompatible change Yes, indeed it would.
  • neuronexmachina 2y ago
    Yes, from PEP 760's draft: https://peps.python.org/pep-0760/ https://peps.python.org/pep-0760/ > This change is not backwards compatible. Existing code that uses bare `except:` clauses will need to be modified. To ease the transition: > * A deprecation warning will be issued for bare `except` clauses in Python 3.14. > * The syntax will be fully disallowed in Python 3.17. > * A `from __future__ import strict_excepts` will be provided to invalidate bare except handlers in earlier versions of Python. > A tool will be provided to automatically update code to replace bare `except:` with except BaseException:
• jmyeet 2y ago
  I'm not a fan of this for two reasons. First, consider this motivation from the PEP: > Requiring specific exception types makes the programmer’s intentions clear and encourages thinking about what exceptions might occur. This reeks of the same rationale for checked exceptions in Java. That was a failed experiment. You can't force people to deal with exceptions. They end up just swallowing them instead. It's better to propagate an exception than do that almost all the time. Like will we see except: replaced with except object:? I don't even know if that's valid. It's never come up. Second, this would be a breaking change. I really feel like this is where Python 3 went off the rails. In the Python 2 days making breaking changes was essentially verboten. But ever since Python 3 decided breaking changes were OK< it's like there's little restraint now and minor releases seems to be far too comfortable with this.
  • paiute 2y ago
    Exactly, python is not Java. I don’t want it to be. There are perfectly good cases to catch all exceptions like this.
    • williamsmj 2y ago
      I'm weakly opposed to the PEP, but if your concern is that you're going to lose the ability to catch all exceptions in new code, then that's wrong as discussed in the Backwards Compatibility section, i.e. do "except BaseException".
  • Scubabear68 2y ago
    You nailed it on both counts. Going back more than a quarter century ago (!), I was one of those zealots in favor of checked exceptions in Java. It took a good 15 years to finally conclude the “checked” part is more trouble than it’s worth. Given that there is inevitably a root context for any given language invocation (main() for a command li program, top of a thread for a multi threaded app, etc), unchecked exceptions and a top level handler have proven to be more than enough. I won’t comment on Python backwards compat, will just shake my head.
• cuuupid 2y ago
  If I’m understanding this correctly this proposal would fully break compatibility with many (most?) codebases, actually remove syntactic sugar and force more characters for the same functionality. I fail to see how this is even being considered. I don’t understand the idiomatic viewpoint either here, I understand the author personally finds it confusing when excepts aren’t verbose but I think you would be hard pressed to find many python developers who agree. Even outside the ecosystem, most languages have been adding more support for bare excepts (like js with bare catch) so this feels like a step backwards. But maybe I’m just not understanding this proposal!
  • Larrikin 2y ago
    Python feels like they are fixing the language the best they can by slowly and properly adding explicit types. Character count is not a valid argument when we have hard drives that are multiple terabytes and IDEs and LLMs that will gladly auto complete a full word with the import. Foo, bar variable names and i, n incrementers should be banished to freshman level undergrad tests meant to intentionally confuse the student. I'm hoping Python 4 will be a big breaking change similar to the previous one and full support for explicit types will be one of the reasons.
    • AlexandrB 2y ago
      Character count is a valid argument because a human is going to have to read the code at some point. Otherwise, Java style names like "countriesFromAsiaWhereAreTheMostPlanesAndBoats" would be just fine. Edit: I don't get the hate for "i" or "j" as increment variables. When you're working with numerical data they closely match how you would express the same operation with mathematical notation and are idiomatic to the point that everyone with non-trivial experience in programming knows what they represent. There are better options in some cases (e.g. "for name in names:"), but there's nothing inherently wrong with i, j, k, etc.
      • Larrikin 2y ago
        But that's a ridiculous example you're proposing in bad faith. I flag nearly all abbreviations in code reviews because code is meant to be read and the names of things should be clear.
• peterhadlaw 2y ago
  What does Tim Peters think about this change?
  • williamsmj 2y ago
    We may never know https://news.ycombinator.com/item?id=41234180 https://news.ycombinator.com/item?id=41234180.
    • drcongo 2y ago
      [ranier-wolfcastle-that's-the-joke.jpg]
• hyperion2010 2y ago
  I'll add a 4th rationale: 4. It will create work for countless developers which is completely consistent with the python core value of disdain for other people's time. If this pep were implemented I suspect it would result in forcing thousands of not tens of thousands of people to spend hours modifying perfectly working code and destroying the ability to run old scientific code without modification. Extremely effective industrial sabotage if it were to be accepted. It is hard for me to articulate how much peps like this reinforce my desire to never start another python project. Even if this pep is rejected the fact that there are people who would put in the time and effort to write and submit such a PEP tells me that they will do it again, and eventually they might succeed.
  • sdenton4 2y ago
    On the bright side, turning bare exceptions into types exceptions is the kind of thing an llm is great for. It's also basically zero cost for new code. On the other hand, I completely agree that it's not worth a breaking change.
    • relaxing 2y ago
      Does that even require an LLM? It should be possible through traditional static analysis.
      • pansa2 2y ago
        Everything requires an LLM nowadays.
        • DrillShopper 2y ago
          Especially if you want to get funding
      • diggan 2y ago
        > It should be possible through traditional static analysis Even better/worse, could do it with regex on text streams.
• new_user_final 2y ago
  [flagged]
  • dang 2y ago
    Please don't cross into personal attack / name-calling, or post shallow dismissals of other people's work. As the site guidelines say, a good critical comment teaches us something. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
• Waterluvian 2y ago
  The existence of two opposing PEPs says to me that there may be a case to be made for either side, so we should default to not changing things. I used to think it’s likely that you can make a much stronger case for one side, but I personally feel that’s more for early language development phase. If it’s been a certain way for a long time, it ought to be overwhelmingly obvious and overwhelmingly supported by the community to change it. And even then I feel a bit of doubt.
  • williamsmj 2y ago
    If you're referring to this PEP's "twin", i.e. "PEP 758 – Allow except and except* expressions without parentheses", that is not an opposing PEP. These two PEPs are orthogonal. One does not contradict the other. They are twins only in the sense that they are both about exception handling syntax.
    • Waterluvian 2y ago
      I’m trying to find it but I thought there was a PEP specifically about the relaxed behaviour of except. I might be wrong here.
• saikia81 2y ago
  Python errors are a mess. It's no surprise people overuse bare except clauses. Disallowing them is not the solution we need.
  • dopylitty 2y ago
    They really are hard to work with compared to languages where you declare which exceptions you'll throw,. I always get angry when pylint raises an error for catching over-broad exceptions[0] Of course I'm catching broad exceptions because I have no idea what kind of exception is going to be thrown 12 dependencies deep and I don't want it to completely crash the program instead of letting me retry or do something else. 0:https://pylint.readthedocs.io/en/stable/user_guide/messages/warning/broad-exception-caught.html https://pylint.readthedocs.io/en/stable/user_guide/messages/...
    • byb 2y ago
      100% agree. Most of my bare except: are followed by import pdb;pdb.set_trace() so I can figure out what went wrong and then fix my code so that it never happens again, but I still leave it there because I I don't have time to consider the millions of ways my hastily thrown-together python script is going to fail nor do I want to game out how many different errors could happen. If Python would have been this hard to use 20 years ago, I wouldn't have been able to learn to program.
    • dmart 2y ago
      Yup this drives me crazy. I've been bitten by urllib3 or SSL exceptions being bubbled up by random libraries so many times that now I always include an except Exception: block just in case.
• joshkel 2y ago
  Interesting. The way I was taught Python, you really, really don't want to use bare `except:`, because it catches _everything_: Ctrl-C interruptions, system exit, etc. Instead, you really ought to use `except Exception:` (where `Exception` is the base class for any "normal" runtime error). So I definitely understand the rationale, but it's hard to say it's worth the pain of backward incompatibility - we have linters, style guides, etc. that can catch this.
  • wild_pointer 2y ago
    Yes, I was bitten by it in the past. Still, it'd better be a lint, or at least a very very long deprecation period... like, deprecated and removed in Python 4 or something.
    • shadowgovt 2y ago
      Having your linter catch `except:` is both simpler and cleaner than changing the language.
      • dtech 2y ago
        Deprecating without removing ever seems reasonable
        • shadowgovt 2y ago
          How does deprecation without removal differ from a best practice? All features of a language end up used, regardless of deprecation state.
          • dtech 2y ago
            I steers people who don't know better away in numerous ways, e.g. most editors with language awareness will give some kind of visual indication like a strike-trough.
  • dimator 2y ago
• OscarCunningham 2y ago
  One example of a time I used a bare except was when I wanted a program to retry three times if it failed for any reason. I just wrapped everything in a for loop with a catchall except. The problem occurred when our scheduling program (Airflow) noticed the program was taking too long to run and decided to kill it. It sent a kill signal to Python, which dutifully caught the exception, retried and continued to run. I had to add a special case to allow Airflow to kill the program. This PEP just forced me to look up the difference between the classes Exception and BaseException. It turns out that BaseException includes every exception, whereas Exception excludes those that are trying to exit the program (like SystemExit and KeyboardInterrupt).
  • williamsmj 2y ago
    With a bare except, your code will continue to retry even if SystemExit or KeyboardInterrupt is raised. This is almost always a bug. In other words, your comment is an argument for the proposal! I don't think it's a good enough argument to make a backwards incompatible change. This is a wart Python has to live with now. But I do think it's a shame that bare excepts behave in a way that is almost always a bug.
    • bee_rider 2y ago
      Maybe bare excepts could be modified to just catch Exceptions. It seems like a reasonable expression of the idea: everything that could go with my program but not with the OS.
      • williamsmj 2y ago
        Personally I think that would have been a better choice in Python's original design, but to change it now would be a backwards-incompatible change, i.e. it suffers from the same big problem everyone is highlighting in the PEP.
      • kstrauser 2y ago
        That seems less bad in the sense it would affect fewer people, but the ones it did affect would likely be much more strongly affected. For instance, I could imagine someone with an old daemon that had a too-level loop like: while True: try: serve() except: log(‘oops’) so that it was more or less bulletproof. This might be a highly unpleasant change for those people who counted on it running 24/7 and never dying. In other words, the current behavior is a minor hassle for many people. That change would be a major hassle for a few. I’d be all for a deprecation warning on bare excepts. That might nudge a lot of people to fix their code without actively breaking anything.
• pansa2 2y ago
  In terms of “break everyone’s code for no good reason”, this proposal is comparable to the removal of the `print` statement.
  • kstrauser 2y ago
    At least that one was beneficial in the long run. It had clear advantages beyond purity.
• graemep 2y ago
  This reeks of "our users are idiots and we need to keep them away from sharp edges". A bare except is something to be flagged up by tools, not disallowed by the language. It is definitely not worth a backward-incompatible change. I am slowly going off Python.
  • forgottofloss 2y ago
    "our users are idiots and we need to keep them away from sharp edges" is exactly what keeps driving me away from Python and pip. It's why I wrote https://pip.wtf https://pip.wtf -- Python package management would be so simple if they'd just stop adding more and more seatbelts and cushions to Python.
    • rurp 2y ago
      No kidding about pip. The dependency resolver change several years ago was a similar terrible move to the PEP being considered here. It broke so much legitimately working code for no good reason; just paternalism from the core devs. The change pushed my team to stop using pip at all for dependency management.
      • kstrauser 2y ago
        Hard disagree there. It was way too easy to get yourself into an incompatibility hell with the old resolver, where package A relied on transitive dependency X v1.2 and package B needed X v2.1. Which version of X you got depended on whether you installed A or B first. Yes, the new version did mean I had to straighten out a few projects that were already working before, but they were working by coincidence because my code paths weren’t stumbling across the incompatibilities. The problem already existed. The new resolver just exposed it.
        • rurp 2y ago
          My case was different from yours. Our project wasn't working by coincidence, the dependency resolver was flagging incompatibilities that simply didn't apply to our case, and began refusing to build a stable working project. Yes it's more risky to override that kind of guardrail, that's why I would only do it when I know the risks and tradeoffs and determine it's the best course of action on balance. I strongly believe that tools should ultimately work for the user, over dogmatic principles. I'm fine with the those safety guardrails being the default behavior, but removing any sort of escape hatch because the pip devs think that they know better than the users of the tool 100% of the time is what I object to. In the end we ended up ditching pip entirely for this use case and ended up with a much better system, with absolutely no disasters as a result, but we had a burn a lot of time and angst that could have been spent on actual problems we were trying to solve.
• wiz21c 2y ago
  Let me check, we're not the first of April, are we ?
• bjourne 2y ago
  As others have stated this idea is gratuitous breakage. Hope it won't become reality.
• aftbit 2y ago
  One must imagine Sisyphus happy. Python just loves to break working code on a regular basis with its new releases. If your code is protected from untrusted user data and the internet, Python 2 is actually a really nice language that doesn't constantly force rewrites. Oh, you want to know the naive UTC datetime in Python, to interface with something like PostgreSQL that recommends naive times? Back in the old days, a simple datetime.datetime.utcnow(). Now days, you need something like: try: from datetime import UTC as tz_UTC except ImportError: from pytz import UTC as tz_UTC dt = datetime.datetime.now(tz_UTC).replace(tzinfo=None)
  • bigstrat2003 2y ago
    > If your code is protected from untrusted user data and the internet, Python 2 is actually a really nice language that doesn't constantly force rewrites. If Python 2 is acceptable for your use case, then you could stay on an old version of Python 3 just fine as well.
    • echoangle 2y ago
      I think the point was making sure that code won’t break in the future. If you tell someone „use python 2 to run my script“, you know it’s going to work basically forever because the latest python 2 won’t be changed. That’s not true for python 3. I still think it’s a bad argument, but that’s what I understood the idea as.
      • cdrini 2y ago
        That argument still seems inconsistent to me, since saying "use python 2, pin your dependences and never upgrade python so your script runs forever" is the same as "use python 3.12, pin your dependences and never upgrade python so your script runs forever".
        • echoangle 2y ago
          Well you can’t update python 2 so there is nothing to pin
• torginus 2y ago
  will this be one of those wonderful changes that will make most python programs unrunnable on contemporary versions of python?
• bee_rider 2y ago
  They explicitly describe the PEP as evil, is there a tradition in the Python community for having obviously terrible PEPs, just to document the reasons for not doing something? Because that would make this a lot more understandable.
  • arp242 2y ago
    If it's not a serious proposal then that's even worse, because there's a long discussion on that thread. So this non-serious proposal is just wasting people's time.
  • eesmith 2y ago
    There is PEP 666. https://peps.python.org/pep-0666/ https://peps.python.org/pep-0666/ > I figure if I make this PEP, we can then ask Guido to quickly reject it, and then when this argument next starts up again, we can say ‘Guido isn’t changing things to suit the tab-haters or the only-tabbers, so this conversation is a waste of time.’ ... > This proposal, if accepted, will probably mean a heck of a lot of work for somebody. But since I don’t want it accepted, I don’t care. I don't know if there are others.
  • veggieroll 2y ago
    Genius-level risk taking
    • bee_rider 2y ago
      Kinda yah, I mean, it seems like it is getting a strong negative response based on the poll.
  • jjice 2y ago
    This was on April Fool's Day, but the roman numeral constants PEP always gives me a laugh https://peps.python.org/pep-0313/ https://peps.python.org/pep-0313/
    • bee_rider 2y ago
      > Any literal composed entirely of M, D, C, L, X, V and I characters that does not follow this format will raise a syntax error, because explicit is better than implicit. Good as a reminder that rules like “explicit is better than implicit” should not be followed all the way to the most absurd possible conclusions.
• williamsmj 2y ago
  I have mixed feelings about this. There are two "problems" this PEP is trying to solve. One is that bare excepts are permitted. The argument against this is that explicit is better than implicit. A matter of taste, but I don't find this convincing. The other problem is what bare excepts mean. Bare excepts are syntactic sugar for `except BaseException`. This means that an application containing a bare `except` followed by the vast majority of real-world error handling will continue to run even if SystemExit or KeyboardInterrupt is raised. This is almost always a bug. I do find this second argument convincing, and I wish Python did not contain this design wart. If I could go back in time and change Python syntax, it would make it hard for people to silently treat these special interrupts as "handleable" like regular errors. The tiny set of applications that really can and should handle them (e.g. TUIs or the mailman example discussed in the final section of the PEP) can explicitly do so with e.g. `except KeyboardInterrurpt` or even `except BaseException`. But I agree with the consensus here that this does not rise to the level of something being worth a backwards-incompatible change.
  • theamk 2y ago
    Disagree. I do this kind of code all the time: try: something() except: log_tons_of_debug_info() raise and I am very glad that I get my debug info works even if I press Ctrl-C or someone calls sys.exit().
    • bee_rider 2y ago
      I dunno, this just usually means I’m going to hold control and mash C, hopefully I can get my interrupt to occur inside your except
      • rcxdude 2y ago
        That's unecessary, because of the 'raise' statement. This construct effectively only hooks exceptions, it doesn't swallow them.
      • encoderer 2y ago
        Signals are non-reentrant.
• tln 2y ago
  -1000 Why would you ever consider breaking everyone's throwaway scripts?? For what is already a universal linter rule?
  • smohare 2y ago
    [dead]
• MantisShrimp90 2y ago
  I think Rich Hickeys advice of not breaking people applies here. The anger from this potential change is that really all you are doing is taking something away that was working, and now people will need to review their code or keep python on a previous version which sucks. I think that people who propose these kinds of changes don't appreciate the importance of the programming language being at the bottom of the stack so there's really never a good reason to break people even if you think it's nicer as you really can't appreciate how much work you are creating for people.
  • TeddyDD 2y ago
    Python breaks compatibility across minor versions. I'm not surprised seeing such proposal.
    • dimator 2y ago
      do you have examples?
      • sseagull 2y ago
        One painful one that is still reverberating a bit in some areas is the renaming of "SafeConfigParser" to just "ConfigParser" in the standard library (in 3.12). This caused a whole lot of breaking in some areas because versioneer (a package for determining a package version from git tags) used it (in code that was placed inside your package, and so couldn't be solved by just upgrading versioneer). Also, I'm starting to get warning about something in tarfile that I will need to track down: https://peps.python.org/pep-0706/ https://peps.python.org/pep-0706/
      • mardifoufs 2y ago
        I think distutils is a good example of that (though imo it's a justified break, but still)
      • gkbrk 2y ago
        There's many, but here's just one. Python 3.7.9 (default, Aug 23 2020, 00:57:53) [Clang 10.0.1 ] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import cgi >>> Python 3.13.0 (main, Oct 8 2024, 01:04:00) [Clang 18.1.8 ] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import cgi Traceback (most recent call last): File "<python-input-0>", line 1, in <module> import cgi ModuleNotFoundError: No module named 'cgi'
• INTPenis 2y ago
  That's funny, I code a lot of python but I don't participate in any large projects where a pipeline might fail due to this. So I don't follow the PEP news much. And yet I have created my own habit of not using bare excepts. TIL what bare except even means, but I do not use them. Simply because I think it makes more sense to specify the exception I want to catch, and failing that I specify the base class Exception. So I guess I understand the author of this PEP, we're of one mind on this. :) Also thanks to this post TIL that a bare except might catch interrupts like ctrl-c. Even more justification for my new habit.
• cpburns2009 2y ago
  The proposal (not part of PEP 760) to add an implicit `raise` to the end of bare `except:` blocks would be far more damaging than making bare-excepts a syntax error.
  • ramses0 2y ago
    [Citation Needed]?
    • cpburns2009 2y ago
      > Now there’s an interesting idea: don’t make bare except illegal, make it have an implicit raise at the end (and disallow return, break, and continue). https://discuss.python.org/t/pep-760-no-more-bare-excepts/67182/10 https://discuss.python.org/t/pep-760-no-more-bare-excepts/67...
      • ramses0 2y ago
        ...ahh, a bit of a misreading on my part. However, I was really looking for your explanation of the horrors that could happen rather than what the suggestion was. Thinking through a bit more, yeah, implicit re-raise does have some pretty bad outcomes if you can't change code in a dependency. It still feels like `deno` is somewhat on the right track where permissions are dropped by default, but It'd Be Nice(tm) if programming languages enabled that a bit easier. import sales_tax_calculator as xyz with [ cap.NETWORK, cap.FILESYSTEM, cap.USB, ...etc... ] xyz.calculate( sales_price, state=user.address.state ) We're implicitly allowing imported libraries the full power of the containing programming language where with promiscuous code sharing (trending towards a low-trust environment), it'd be a lot better to _not_ give `cap.FS, NETWORK, USB, etc...` by default. Bringing it back around: `import somelib with [ cap.BARE_EXCEPT, cap.RAISE ]` or something to control their handling of "unknown" exceptions is interesting. Let them handle any exceptions or interrupts they've authored, but let me explicitly have control over catching stuff that isn't "from them". ...an extended version of dependency injection or inversion of control.
        • 2y ago
• shadowgovt 2y ago
  I'm not categorically against it, but it needs to go into Python4, not a minor revision. It breaks too much. (Plus, the suggested transition easement, "A tool will be provided to automatically update code to replace bare except: with except BaseException:", indicates a fundamental flaw in this approach: it's still trivial for developers to catch-and-kill exceptions. So we're strictly increasing the verbosity of the language without actually solving the problem. :( ).
• stackskipton 2y ago
  This is what not having sane BDFL does to organization. Only proper response is private email from sane BDFL similar to Linus email of "WE DON'T BREAK USERSPACE"
  • Chris2048 2y ago
    This is just a proposal though, having a (sane) BDFL needn't change anything.
    • stackskipton 2y ago
      Sane BDFL would have already stepped in with "Absolutely not" and PEP closed with "Will not implement" EDIT: Add on, Private Email to Pablo going "Dude, why are you purposing stuff that will break code spectacularly? I think we need to talk about your approach to language design."
      • int_19h 2y ago
        The community (including many of the maintainers) has spoken, and the PEP has been withdrawn, so apparently you don't need a BDFL for this.
  • gklitz 2y ago
    They are literally trying to depreciate a feature that regularly breaks user space because it’s unintentionally misused. I don’t think I’ve ever come across a use case where people actually intended to write a bare except. Anyone who ever does this are actually thinking that it’s effectively the same as “except Exception” which it isn’t, but that’s more obvious to most users.
• byyoung3 2y ago
  they might as well add semicolons while they are at it
  • akuchling 2y ago
    Erm, Python has accepted semicolons to separate statements since version 0.9.2, released in the fall of 1991.
    • byyoung3 2y ago
      bruh i mean make them mandatory
• deleted 2y ago
  [deleted]
• shadowgovt 2y ago
  FWIW, on the poll near the bottom of the comment thread, "I think we should always allow bare except blocks" is winning significantly.
• deleted 2y ago
  [deleted]
• dataflow 2y ago
  > which can lead to overly broad exception handling and mask important errors I'm sure it can, but some evidence of this actually happening feels rather critical for a change that will break the language for everybody.
• pech0rin 2y ago
  Cant stand the infantilization of software tools. People can choose for themselves what features to use or not use. Doesnt need to be determined by our keepers. Also do Python maintainers just hate backwards compat as some sort of religion?
• eesmith 2y ago
  Yeah, no. I know I'll mistakenly do except Exception: resource.rollback() raise instead of except BaseException: resource.rollback() raise and it's going to be really hard to insert a test case which ensures I really handled KeyboardInterrupt and the like.
• AnonsLadder 2y ago
  [flagged]
• prpl 2y ago
  This is something that can be handle easily with static analysis and should not be a language feature
• pjmlp 2y ago
  I hope this goes nowhere, it adds very little value, to the expense breaking compatibility.
• bunderbunder 2y ago
  I get that lately Python has decided it wants to be an industrial-grade enterprise programming language. But there's a part of me that misses when the Python community retained a "we're all adults here" ethos.
• move-on-by 2y ago
  I just completed upgrading a monolith from Python 3.8 to 3.11 - no doubt many others in the same position with 3.8 going EOL. It was a monumental effort. I will say the huge majority of work was upgrading libraries that hadn’t been updated in years. I won’t go into the specifics of why we had chosen not to update these libraries earlier (unless there is interest), but I will say Python being as backward compatible as possible has huge real world value. More for the community and ecosystem than the language itself. For the people who care about PEP 760, they have their choice of linting tool to enforce this requirement.
• b5n 2y ago
  I've spent a lot of time fixing/explaining python exceptions over the years, and I get pretty annoyed when I encounter bare exceptions. Exceptions themselves are so often misunderstood, it seems most people just take them at face value. However, do we really need to dull all the sharp edges and add guardrails to every fucking thing? In a corporate environment, sure, you can implement all the protections you like _without attempting to force your constraints on all users_. If you care about types, safety, etc. there are plenty of fantastic projects that share your priorities, but they don't need to bleed into everything under the sun. Sharing and adopting new ideas is healthy, but homogenization kills creativity. Maybe I'm just grumpy today.
• berdario 2y ago
  A bunch of people are mentioning the bugbear of the Python3 migration, but there's an important difference that makes the migration a lot simpler for a backward-incompatible change like this one proposed in PEP760: You can just write code that is compatible with Python runtimes both before and after the change. That means that you can use the same test suite, gradually getting the code more and more compatible with the new version, and you can switch your production runtime, without having to worry about a more complicated and involved rollback process. Notably, in the Python 2->3 migration, it was not really possible (at first[*]) because "" (and b"") literals became -> b"" while u"" literals became -> "" So, there was no way to write literals that would mean the same thing, and have the same type across the two versions This is also the reason why libraries like six offered a `six.u` function (https://six.readthedocs.io/#binary-and-text-data https://six.readthedocs.io/#binary-and-text-data) but that required banning use of non-ASCII codepoints in your string literals [*] This was eventually addressed with PEP 414 (and of course, even with with PEP 414, the migration was not trivial) https://peps.python.org/pep-0414/ https://peps.python.org/pep-0414/
  • move-on-by 2y ago
    > That means that you can use the same test suite, gradually getting the code more and more compatible with the new version, and you can switch your production runtime, without having to worry about a more complicated and involved rollback process. This is all well and good for your own code, but it’s seldom the case the libraries. A new library release that ‘adds support for Python 3.14’ is very likely to include other changes in the same release that may or may not be trivial, even assuming you were already on the latest version of the library prior to needing to update. A change like this to the Python language might be trivial, but it would have a massive impact on the ecosystem.
    • berdario 2y ago
      > A new library release that ‘adds support for Python 3.14’ is very likely to include other changes in the same release that may or may not be trivial There's no reason to believe that would be the case. The exceptions are: - add support for Python 3.0 (that's of course a very different situation as I described before) - eagerly adopt TONS of Python 3.14-only features (of course that means a different thing than "adds support for") What a specific release claim to do is irrelevant. The library should run its test suite in CI against multiple Python versions. in this specific case, updating to 3.14 just mean that the library stopped using bare excepts, which means that all version of Python pre-3.14 would still be able to use the library as usual (and thus, CI of those python versions can be retained). If you're running a library with a version of Python against which it's not tested, of course you're in a precarious situation (and a bug that silently causes your code to behave differently is going to be a lot more tricky to deal with than a bit of syntax which is not supported anymore).
• ck45 2y ago
  I don't remember there to be that much complaint about https://peps.python.org/pep-0352/ https://peps.python.org/pep-0352/ and from having worked on a large Python code base at that time, it was rather easy change.
• amelius 2y ago
  Next step: ... except Exception as err: pass Error: variable err not used!
• BurningFrog 2y ago
  I've had and seen this philosophical debate a few times. To me, "if anything goes wrong, do the following" is perfectly valid semantics that appears a lot, and a bare excepts is a fine way to implement that. I think what confuses these discussions is that a common "rookie mistake" is slapping on a bare except when you really should be specific. For some people, this is reason enough to blindly enforce a "bare excepts" rule. To me, the costs vastly outweigh the benefits in this case. At it's core, this might be a personality type issue more than anything else.
  • dtech 2y ago
    The pep explicitly adresses the use case, and it's still allowed. The point of the pep is that it should be explicit, especially because the short form doesn't show whether catching terminating exceptions is a bug or intentional
  • _hl_ 2y ago
    What’s wrong with being explicit about “I really do mean anything that goes wrong” by catching the base class?
    • BurningFrog 2y ago
      That's actually the better way for me as well! So my comment is somewhat off topic. I still don't like the proposed change because of how much existing code it would break, but if we're designing a new language I approve.
      • _hl_ 2y ago
        I see - I suppose that’s a fair viewpoint to have! I’m not much of a python programmer but my experience with the language would make me tend to agree actually. There are bigger fish to fry and so the effort to go after this relatively tiny sardine is perhaps not worth it.
    • nomel 2y ago
      I don't understand this. To me, a bare exception is explicitly that. By not providing a specific exception, you're saying "nothing specific, literally anything".
• veggieroll 2y ago
  I switched to Go years ago because I know that code I wrote a decade ago is still going to work. And that guarantee is even more ironclad in recent years with modules and vendoring. With a Go project, I can leave it to sit for 3+ years and then pick it back up and add a feature without any issues. I've never had that with a Python project. (and this isn't even about the 2-to-3 situation, I just mean minor version to minor version and packages)
• czscout 2y ago
  Personally, I don't agree with this proposal. While yes, I agree, that bare excepts are often a source of bugs, I don't think it should be the language's responsibility to nanny the programmer on such things. To me, this seems to only reduce the functionality of the language. If explicit exception handling is necessary, let the programmer make that decision.
• berkayozturk 2y ago
  Even though there are valid use cases for having catch-all clauses, I see people forget about properly handling SystemExit exception. If your service receives SIGTERM from the scheduler, you need to capture it and gracefully handle the shutdown instead of swallowing it.
• kristjansson 2y ago
  My concern, and IMO what should be the overwhelming concern of the maintainers, is not the code that is being written, or the code that will be written, but all the code that has been written, and will never be touched again. A break like this will force lots of python users to avoid upgrading to 3.17, jettison packages they may want to keep using, or deal with the hassle of patching unmaintained dependencies on their own. For those Python users for whom writing python is the core of their work that might be fine. For all the other users for whom python is an foreign, incidental, but indispensable part of their work (scientists, analysts, ...) the choice is untenable. While python can and should strive to be a more 'serious', 'professional' language, it _must_ have respect and empathy for the latter camp. Elevating something that should be a linter rule to a language change ain't that.
  • rurban 2y ago
    major changes with breaking backward compatibility would require a major bump. Fine for python 4 I would say.
    • kristjansson 2y ago
      Sure I guess? But we've just barely stopped talking about Python3, and that was released 13-16 years ago[1]. Is _this_ change worth another decade of thrashing the ecosystem? Is __any__ change? [1]: depending on if we count 3.0 vs 3.2 when it was actually kinda usable.
    • nine_k 2y ago
      Why, it just should be opt-in: from __future__ import no_bare_except ...and enjoy.
      • afiori 2y ago
        Python should have the ability to set per-module flags for these kinds of incompatibilities. I guess that __future__ is doing something similar, but I am thinking of something like declaring how options should be set for your module and then only the code in that module is affected. (It would be nice being able to set constraints on what options your dependencies can enable) I guess that for std functionality this is impossible (like if the dict changed its key sorting it might be too hard to dispatch on the original file) but for syntax it should be perfectly possible.
• martinbaun 2y ago
  I love Python, but it seems to always get more complicated and more things in the core and now backward incompatible changes. Not so good. I love Python and how much I can get done, but I must admit I also love that I know the Go code I have from 7 years ago can run without problems. It is just more stable
• kh_hk 2y ago
  Seems like a troll PEP and still would not surprise me. Explicit is better than implicit, except if it makes you look like a fool.
• lpapez 2y ago
  If this was Go, instead of making a breaking change they would opt for a linter rule or a go vet directive. This is the sensible approach IMO to handle a hazardous programming construct. Warn people about it and give them the choice to shoot their foot. But don't break their code.
• ziml77 2y ago
  Fortunately the votes on the poll for this look to very much be against the PEP's proposal. I don't mind Python being improved, but as we learned from the 2->3 transition it should not be changed in ways that break old code. All that will do is have people forever sitting on an old version of Python. That's a worse situation that having code with bare excepts.
• xorcist 2y ago
  Valid reasons for backwards incompatible changes to language syntax: 1. The language guarantees have become inconsistent, and the syntax breaks security boundaries or realtime guarantees that the language explicitly promises, and it is unfixable. 2. The universe of all written code is small enough that there are guarantees the syntax is unused, or we can change all instances of the syntax in an atomic manner. Invalid reasons for backwards incompatible language changes: 1. Everything else.
  • throw16180339 2y ago
    I disagree with this, because there are a lot of fairly benign language extensions that break compatibility in pathological cases. Here's a C example. C90 supported block comments with /* comment */. C99 added BCPL style comments with // the rest of this line is a comment They were already a common language extension and supported by C++. Here's an example of C90 code that fails to compile under C99 because of // comments. int x = 12; int y = x //* I'm placing a comment here just to be difficult.*/ 3; Should the committee have rejected this change to prevent breaking programs with similar code?
• dsign 2y ago
  I know what this is! They want to "to give it" to Jeff Bezos, by breaking AWS' boto3, that has a nightmare of a story for handling/catching specific exceptions. It's all politically motivated!
• kkirsche 2y ago
  I wish people would stop holding onto compatibility as if it is some amazing feature. It has benefits, but also comes with many drawbacks to innovation and improvement in established ecosystems
• smbullet 2y ago
  This seems silly. I hate backwards compatibility but this change will just cause people to use `except BaseException` everywhere which seems even less idiomatic than bare excepts. ETA: Nobody is going to dig through a large codebase to find exactly what exceptions can be bubbled up if they didn't design it with explicit exception handling in mind from the beginning. It will also potentially become a pattern people will copy in new code.
• jgb1984 2y ago
  As someone who is using python professionally for over 17 years I sincerely hope this PEP gets rejected.
• Scea91 2y ago
  Not all python code is production code. Sometimes I just need to write simple one-off script for one-off task. For that bare except is totally fine.
• zmnayt 2y ago
  As many people have observed here, this is a couple of Steering Council members showing activity. Getting one's PEPs accepted has a totally inflated weight in the Python "community". The more, the better (by contrast very few people care about perfect and bug-free code). So, if this thing is accepted, it pads the resume of certain people even more. And many software orgs will have one additional week of job security by rewriting existing code. It's a win-win situation. Ever since the walrus operator coup Python has descended into madness and make-work initiatives.
• wyldfire 2y ago
  > Currently, Python allows catching all exceptions with a bare except: clause, which can lead to overly broad exception handling and mask important errors. The fact that this pattern catches NameError and other things which are obviously design errors means that it is a really bad behavior which is unfortunately common. Of course, many folks in this comment section and the PEP discussion thread point out the pitfalls with the suggested remedies. It would be great if some amount of linting/warning/static check could be devised to help people uncover the problem though.
• joshlk 2y ago
  Would it be possible to move all the language developers to work on packaging? IMO the Python language is feature complete but the packaging system needs heart surgery.
• deleted 2y ago
  [deleted]
• dcchambers 2y ago
  ELI5: Why do people love Python so much? From an outsiders perspective: The ecosystem is a disaster, on a level even exceeding that of JavaScript IMO. The 2->3 transition was awful and lead to a rift in the python community for years (still causes issues 15 years later). Maintainers seem happy to introduce breaking changes without major version bumps. It's not that performant of a language (slower than modern Ruby, for example). Best thing it's got going for it is readability.
  • gnulinux 2y ago
    Python ecosystem is a disaster for certain reasons but there is simply no ecosystem better than Python for other reasons. It's a trade-off. For literally any niche problem you can find out there there will be a Python library somewhere in the annals of the internet. I use many many many programming languages and everything starts out as a Python script in my flow, because by the time you start half the code is already written.
  • linguae 2y ago
    Python is not my favorite programming language, but back in 2006 Python felt like a breath of fresh air for writing short programs. I felt more productive in Python than in C, C++, or Java, which were the other languages I knew at the time (I was an undergraduate CS student), and I still use Python as my first choice for short data processing scripts. In addition, Python has many libraries, built-in and external. When I worked as an AI researcher before returning to academia, Python was our team's main language since there's a rich ecosystem of numerical computing and machine learning libraries. I agree, though, that the ecosystem has many rough edges, especially when it comes to package management, dependency management, and environments/containers. This is especially true in the AI ecosystem, especially as a researcher, where I had to deal with third-party code that is sometimes written by people who are solid scientists but have little software engineering experience. I'm now back in academia as a teaching-oriented professor; it's been a few months now since I've had to use pip and conda, though I have written some Python scripts to aid with grading. I teach C++ and Haskell to undergrads now, and I also have side projects involving Scheme and Common Lisp :).
  • dbrueck 2y ago
• cb321 2y ago
  Possibly relevant -- Nim has a compile-time warning for bare exceptions, initially enabled by default [1]. I think Nim-core changed their mind about this being a good idea a few months later: https://github.com/nim-lang/Nim/pull/21728 https://github.com/nim-lang/Nim/pull/21728 (though the message still says "The bare except clause is deprecated" if you do compile with --warning:BareExcept:on - I think the urge to actually deprecate has gone away). I think for Python, rather than breaking bajillions of unpublished lines of code they should start with a more tentative & minimally invasive environment var/CLI switch opt-out warning that says something like "may be deprecated" where even the Python ./configure script lets you opt out at Python interpreter-compile-time. Measure the scope of the porting problem for a few years before trying to decide on The Plan for something that might be too disruptive. [1] https://github.com/nim-lang/Nim/commit/91ce8c385d4ccbaab8048cf0393b01cd72282272 https://github.com/nim-lang/Nim/commit/91ce8c385d4ccbaab8048...
• gweinberg 2y ago
  This has to be some kind of joke. If it had gone the other way and python had originally required people to write "except BaseException", a PEP to allow a bare except would be an obvious improvement to the language, since it would allow people to do the same thing and save pointless typing. This proposal is suggesting we break virtually all existing Python code to make the language objectively worse. I'm guessing this is a sort of "modest proposal" type parody.
• braiamp 2y ago
  I don't know why this is seen with such aversion. This is the language forcing sane coding practices, since you always include what should be cached. Also, the syntactic sugar for except BaseException is to not catch it in your `try ... except` clause. If you do, for example: >>> try: ... raise TypeError ... except ValueError: ... print("keke") ... raise ... TypeError will bubble up. If you want to catch everything, and handle it, like the example from Mailman[0], you should catch the base exception anyways. This can be solved and detected by static analysis tools anyways. [0]: https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/database/transaction.py#L27 https://gitlab.com/mailman/mailman/-/blob/master/src/mailman...
• thih9 2y ago
  A lot of comments are about this affecting existing unmaintained code and causing problems with upgrades. But couldn’t the old code be automatically updated? E.g. wouldn’t replacing every ‘except:’ with ‘except BaseException:’ make old codebase compatible with the proposed change? Sure, that’s a pain too and I’m not a fan of the change itself either; still, a breaking change that can be addressed automatically sounds relatively easy.
• NelsonMinar 2y ago
  Python is also a scripting language, not just a systems engineering language. Sometimes fast-and-loose error handling is appropriate to the task.
• krzyk 2y ago
  I was afraid that this is something similar to infamous PEP 572 (also known as make-python-c), but it actually is a great change - it will remove errors and will make code more readable (contrary what PEP 572 did).
  • zahlman 2y ago
    You did notice that Guido van Rossum was a co-author of that one, yes?
    • krzyk 2y ago
      Does not change the controversy. AFAIR he quit soon after this PEP was added. Adding it was like making python dirty, like abolishing indentation in it. Saving few keystrokes and sacrificing readability. Who even came out with such idea?
• objektif 2y ago
  This is how beautiful languages are ffed up. Can you leave the core syntax alone and let people write elegant code if they want to? Why do we try to force a certain type of coding down the throat of people. Ease of use made python popular and we should leave it that way.
• wren6991 2y ago
  Someone needs to set up a Clockwork Orange-style viewing session with the Python developers and Linus' WE DO NOT BREAK USER SPACE email: https://linuxreviews.org/WE_DO_NOT_BREAK_USERSPACE https://linuxreviews.org/WE_DO_NOT_BREAK_USERSPACE I help maintain a small Python codebase at work (bulk of my work is in Verilog) and the number of times somebody's PEP science fair project has broken production code following a Python version upgrade is too damn high.
• camgunz 2y ago
  Leave this in linters.
• zitterbewegung 2y ago
  Latest post on this says that this PEP won't be implemented at all. https://discuss.python.org/t/pep-760-no-more-bare-excepts/67182/83 https://discuss.python.org/t/pep-760-no-more-bare-excepts/67...
• kej 2y ago
  The PEP has been withdrawn based on the poll results, which mostly echo the comments here: https://discuss.python.org/t/pep-760-no-more-bare-excepts/67182/83 https://discuss.python.org/t/pep-760-no-more-bare-excepts/67... >Hi everyone! >Thanks a lot for voicing your opinions and concerns! After reading carefully all the arguments, the poll and the different positions we have decided that the best course of action is to withdraw the PEP as there is clear agreement that the breakage doesn’t justify the benefits here. >Thanks a lot!
  • zahlman 2y ago
    What bothers me more on a meta level is that some people in the community are apparently empowered to just write PEPs on a whim that will be quickly withdrawn, whereas most people will be forced to fight through long discussion threads before finding a sponsor willing to co-sign to a PEP (if that ever happens). The "Ideas" section of the forum is probably the least pleasant to use; and for all the controversial new stuff that gets added, the dev team is stunningly conservative WRT ideas that come from outside. In particular, they'll commonly tell you to demonstrate your feature as a third-party package on PyPI first, then show that it gains popularity (i.e. you as a random developer are responsible for promoting your idea, not merely justifying it) - and if you succeed at that, they'll have the argument waiting for you that you already have a maintained, mature library that's perfectly capable of working on its own, so why would it need to become part of the language? "The standard library is where packages go to die", don't you know? BTW, they will also tell you these things if the nature of your idea makes it impossible - e.g., you propose to add a method to a builtin type; subtyping won't work, because part of the point is that literal values should get the functionality automatically.
  • dfhfg 2y ago
    So, after wasting everyone's time they issue a bureaucratic power talk statement that the casual reader will interpret as "nice". They certainly do know how to play mostly socially incompetent followers. (These are the same people who humiliated Tim Peters and others.)
• benrutter 2y ago
  Love the boldness here of trying to make something you dislike a syntax error. I don't really get preferring `except BaseException` over `except`. I'd love to get more info on possible exceptions though and I think it would cut down a lot of the catch all handling I see. As far as I know, python doesn't give you any way of asking "what exceptions can this function run" - aside from just inspecting every line of code. I'd massively love to have those kind of details available.
  • Numerlor 2y ago
    I have suggested adding an option for exceptions into typing as a non exhaustive list of what something can raise so you actually know what you should or shouldn't be handling. But as it usually goes in the forums the discussion just devolved into misunderstanding it as checked exceptions and how code that'd benefit from it is bad because exceptions you don't know about should bubble up
• atoav 2y ago
  Having a catchall exception may seem like a bad idea to some, but I am quite often in situations where I write code that I really don't want to fail (and I want it to continue running). Fore these cases I always used it as such: try: result = somethingrisky() except SomeKnownException as e: return handle_known_error(e) except Exception as e: log_error(e) return None return result or something among those lines. And this is perfectly fine if that risky function e.g involves requests that in my experience can fail for a ton of reasons and it is hard to know them all.
• neeleshs 2y ago
  Looks like this PEP has been withdrawn now
• krick 2y ago
  I really don't see what's even the problem with bare excepts. Yes, I do want to catch all exceptions sometimes. Sometimes, I don't even care what the exception is. I have ignored my linter's suggestion to fix it on multiple occasions. So, why? Ok, I'll use except BaseException then. How is it any better than bare except?
• annexrichmond 2y ago
  Maybe before enforcing such nonsense, they should standardize function docs like javadocs. How are you supposed to know which errors to "except" if it's not documented anywhere anyway?
• Sweepi 2y ago
  From reading the title, I assumed they wanted to make me handle all Errortypes explicitly. However, they just want to replace this: try: risky_operation() except: handle_any_error() with this: try: risky_operation() except Exception as e: handle_expected_error(e) and this will also be legal: try: risky_operation() except Exception as e: pass ... seems fine to me, but its off the table anyway.
• wirrbel 2y ago
  That's a bit ... excessive? A compatibility nightmare of the same magnitude as Python 2 to Python 3 migration.