PEP 760: No more bare excepts

Original Article ↗ Hacker News Discussion ↗

Scope and Status of PEP 760

  • Proposal: disallow bare except: clauses; require explicit exception types (e.g., except BaseException:), with a deprecation path (warning in 3.14, removal in 3.17) and an auto‐fix tool.
  • Update: commenters note the PEP has already been withdrawn after strong negative feedback and a poll against it.

Backward Compatibility and Ecosystem Impact

  • Many see this as “gratuitous breakage” that could affect huge amounts of existing code, including unmaintained scientific scripts and third‑party libraries.
  • Concerns:
    • For old or incidental scripts, maintainers may be long gone; users just want them to keep running.
    • Dependencies would also need updating, not just first‑party code.
    • Past pain from the Python 2→3 migration leaves people extremely wary of more source‑breaking changes.
  • Some argue that even with an automatic rewrite tool, the ecosystem churn and dependency chain breakage are not worth it.

Arguments For the Change

  • Bare except: currently catches BaseException, including KeyboardInterrupt, SystemExit, and others; this often unintentionally suppresses interrupts or shutdown signals.
  • Several commenters share real bugs caused by bare except: (e.g., jobs ignoring kill signals and retrying forever).
  • Supporters see value in:
    • Forcing programmers to think about what they intend to catch (Exception vs BaseException).
    • Aligning with “explicit is better than implicit” and reducing debugging pain.

Arguments Against the Change

  • Many view this as a style/linting issue, not something to enforce in the core language.
  • Linters (flake8, pylint, ruff) already flag bare except:; teams that care can opt in today.
  • Some fear programmers will just mechanically replace except: with except Exception: or except BaseException:, without improving error handling.
  • Critics see a pattern of Python core being too willing to break user code and “infantilize” users by removing sharp edges.

Broader Meta‑Discussion

  • Debate about Python’s non‑semantic versioning and tolerance for breaking changes in 3.x.
  • Comparisons with Rust, Go, Java, C++ and their compatibility philosophies.
  • Frustration that language stewards seem disconnected from casual or scientific users for whom Python is a secondary tool.