[Python-ideas] PEP-3151 pattern-matching

[Guido van Rossum]

With apologies for not reading the PEP or this thread in full, some comments:

- I really like the syntax "except <exc> [as <var>] [if <test>]:".
This addresses a pretty common use case in my experience. I don't care
for the alternate proposed syntax that started this thread. I'm not
sure that the 'if' subclause makes sense without the 'as' subclause,
since most likely you'd want to refer to the caught exception. I note
that it is more powerful than putting "if not <test>: raise" in the
body of the except-clause, because it will allow subsequent except
clauses to match still. I also note that it is a much "cleaner" change
than (again) reorganizing the exception hierarchy, since there is no
backward compatibility to consider.

- Regarding restructuring the exception tree, I don't think this needs
to wait for Python 4. (We've done it several times during Python 2.)
But it is very tricky to do it without breaking existing code, and I'm
not sure that deprecations will help that much. E.g. if two exceptions
A and B are currently not related via inheritance, and we were to make
A a subclass of B, then in code of the form try: ... except B: ...
except A: ... the except A clause would become unreachable. Maybe it's
easier to propose small changes instead of trying to refactor a huge
section of the exception tree?

- Quite independently, I think it is time that we started documenting
which exceptions are raised from standard APIs. The trick is to avoid
overdocumenting: there is no point in documenting that everything can
raise MemoryError or that passing in wildly invalid arguments can
raise TypeError or AttributeError (and pretty much anything else). But
the variety of exceptions that may be raised by something like
urlopen, depending on which layer of the network and I/O stacks
detects a problem are worth documenting. Maybe this example could even
be a starting point for a rationalization of some of the exceptions
involved. (And if we find there are legitimate situations where a
networking or I/O problem raises a "generic" error such as TypeError
or AttributeError, those are probably bugs that should be fixed in the
code.)

- Lastly, there is a bunch of standard exception types that are
usually caused by bad code (as opposed to bad data or an environmental
problem). This would include NameError, TypeError, AttributeError, but
not KeyError, IndexError, ValueError. Perhaps it makes sense to
introduce a common base class for these "bad code" exceptions? Unlike
the other exception types, I think that the set of "bad code"
exceptions is pretty much static; a new library module is not going to
define raise a new kind of "bad code" exception. (But it may well
define a new kind of "bad data" exception, and I don't think we need a
common base class for all "bad data" or "bad state" exceptions.)

-- 
--Guido van Rossum (python.org/~guido)