[Python-Dev] Major revision of PEP 348 committed

[Raymond Hettinger]

VMError -- This is a new intermediate grouping so it won't break
anything and it does bring together two exceptions relating them by
source.  However, I recommend against introducing this new group.
Besides added yet another thing to remember, it violates
Flat-Is-Better-Than-Nested (see FIBTN below).  Also, the new group is
short on use cases with MemoryErrors sometimes being recoverable and
SystemErrors generally not.  In the library, only cookielib catches
these and it does so along with KeyboardInterrupt in order to re-raise.
In general, you don't want to introduce a new grouping unless there is
some recurring need to catch that group. 

EOFError -- I recommend leaving this one alone.  IOError is generally
for real errors while EOF occurs in the normal course of reading a file
or filelike source.  The former is hard to recover and the latter is
normal.  The PEP's justification of "Since an EOF comes from I/O it only
makes sense that it be considered an I/O error" is somewhat shallow and
doesn't reflect thought about how those exceptions are actually used.
That information is readily attainable by scanning the standard library
with 57 instances of EOFError and 150 instances of IOError.  There are a
few cases of overlap where an except clause catches both; however, the
two are mostly used independent from one another.  The review of the
library gives a good indication of how much code would be broken by this
change.  Also, see the FIBTN comment below.

AnyDeprecationWarning -- This grouping makes some sense intuitively but
do we have much real code that has had occasion to catch both at the
same time?  If not, then we don't need this.   

FIBTN (flat-is-better-than-nested) -- This bit of Zen carries extra
significance for the exception hierarchy.  The core issue is that
exceptions are NOT inherently tree-structured.  Each may ultimately
carry its own set of meaningful attributes and those tend to not neatly
roll-up into a parent/subclass relationships without Liskov violations.


Likewise, it is a mistake to introduce nesting as a means of
categorization.  The problem is that many conflicting, though meaningful
groupings are possible.  (i.e. grouped by source (vm, user, data,
system), grouped by recoverability or transience, grouped by
module/container type (dictionary errors, weakref errors, net errors,
warnings module, xml module, email errors), etc.)   

The ONLY useful nestings are those for a cluster of exceptions that are
typically all handled together.  IOW, any new nesting needs to be
justified by a long list of real code examples that currently catch all
those exceptions at the same time.  Ideally, searching for that list
would also turn-up no competing instances where other, orthogonal
groupings are being used.

Vocabulary size -- At one time, python-dev exhibited a strong reluctance
to introduce any new builtins.  No matter how sensible the idea, there
was typically an immediate effort to jam the proposed function into some
other namespace.  It should be remembered that each of PEP 348's
proposed new exception groupings ARE new builtins.  Therefore, the bar
for admission should be relatively high (i.e. I would prefer Fredrik's
join() proposal to any of the above new proposals).   Every new word in
the vocabulary makes the language a little more complex, a little less
likely to fit in your brain, and a little harder to learn.  Nestings
make this more acute since learning the new word also entails
remembering how it fits in the structure (yet another good reason for
FIBTN).

Once again, my advice is not introduce change unless it is solving a
specific, real problem in existing code.  

The groupings listed above feel like random ideas searching for a
justification rather than the product of an effort to solve known
issues.

If the PEP can't resist the urge to create new intermediate groupings,
then start by grepping through tons of Python code to find-out which
exceptions are typically caught on the same line.  That would be a
worthwhile empirical study and may lead to useful insights.

Try to avoid reversing the process, staring at the existing tree, and
letting your mind arbitrarily impose patterns on it.  



Raymond