PEP 760: No more bare excepts

Original Article ↗ Hacker News Discussion ↗

A proposal to ban bare `except:` clauses in Python (PEP 760) triggered strong pushback from developers who rely on the construct and fear another wave of breaking changes reminiscent of the Python 2→3 split. Supporters argued that forcing explicit exception types would prevent masked errors and align with “explicit is better than implicit,” but critics countered that this belongs in linters, not the core language, and would impose huge churn on existing and unmaintained code. With community sentiment and a poll heavily against the idea, the proposal has since been withdrawn, reinforcing wider concerns about Python’s approach to backward compatibility.

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.