[williamsmj]

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]

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.

[kstrauser]

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]

> 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.

[williamsmj]

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.