What does PEP 758 change about `except` clauses in Python 3.14?

## The old rule and where it came from In Python 2, `except ValueError, e:` meant "catch `ValueError` and bind the instance to `e`" -- the comma was the binding syntax, not a list separator. To catch two types you had to write `except (ValueError, TypeError):`, and the parentheses were what told the parser you meant a tuple of types rather than a type and a target name. Python 3 replaced the binding comma with `as` and rejected the old spelling outright, but it kept the requirement that multiple types be parenthesized. That was a compatibility measure: for years, `except ValueError, e:` in a Python 3 file was almost always ported-from-2 code, and a clear `SyntaxError` was far kinder than silently catching two types, one of which the author had meant as a variable name. ## What PEP 758 does By 3.14 that transition is long over, so PEP 758 -- *Allow except and except\* expressions without parentheses* -- relaxes the grammar. Both of these now parse: ```python except ValueError, TypeError: except* ConnectionError, TimeoutError: ``` The change is purely syntactic. The clause still matches by `issubclass`, clauses are still tried top to bottom, and the runtime semantics are exactly those of the parenthesized form. ## The one restriction Adding `as` brings the ambiguity back, so the parentheses remain mandatory there: ```python except (ValueError, TypeError) as exc: # fine except ValueError, TypeError as exc: # SyntaxError ``` The compiler's message is explicit: *multiple exception types must be parenthesized when using 'as'*. The reasoning is that `except A, B as e:` could plausibly be read as the Python 2 form with an extra type, and CPython would rather refuse than guess. ## What it is not Three things PEP 758 does *not* do, and each has been a wrong answer in an interview: * It does not let you write `except ValueError | TypeError:`. The union expression compiles, but at runtime the interpreter reports *catching classes that do not inherit from BaseException is not allowed*, because the `X | Y` union object is not an exception class. * It does not change matching, ordering, or anything about which handler wins. * It does not affect `except*` semantics beyond the parentheses -- exception-group matching is unchanged. ## Should you use it? Only in code that targets 3.14 and above, and even then it is a taste call. The parenthesized form parses on every Python 3, so any library with a lower floor keeps it -- and mixed styles inside one codebase are worse than either style consistently applied. Where it does help is long clauses in application code that has already pinned a modern interpreter: ```python try: rate = load_cached_rate(currency) except KeyError, ValueError, TimeoutError: rate = fetch_rate(currency) ``` The comma form reads a little more like the rest of the language, which is the whole justification the PEP claims; nobody argues it changes anything material. ## Where this shows up in an interview Rarely as a question in its own right, and no interviewer should hold it against a candidate who has not tracked 3.14's syntax additions. It appears more often as a detail inside a broader conversation about handler syntax -- someone reads a 3.14 snippet aloud and wants to know whether you noticed that the parentheses are gone, or asks what would happen if you added `as exc` to it. The useful thing to carry is the pair of facts: unparenthesized lists are legal from 3.14, and `as` still forces parentheses. ## Version summary `except (A, B):` -- every Python 3. `except A, B:` -- 3.14 and later only; a `SyntaxError` on 3.13 and earlier. `except A, B as e:` -- a `SyntaxError` on every version including 3.14. `except*` gained the same relaxation in 3.14, having arrived, parenthesized, in 3.11 with PEP 654.