4 ms·

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 comme

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.
  - williamsmj 2y ago
    > 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. The PEP proposes a deprecation timeline for exactly this.

4 ms·

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 comme

by williamsmj 2y ago

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.
  - williamsmj 2y ago
    > 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. The PEP proposes a deprecation timeline for exactly this.