[Python-Dev] Major revision of PEP 348 committed

[Brett Cannon]

On 8/7/05, Raymond Hettinger <raymond.hettinger at verizon.net> wrote:
> 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.
> 

And Nick didn't like it either.  Unless someone speaks up Monday, you
can consider it removed.

> 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.
> 

Basically you are arguing that EOFError is practically not an error
and more of an exception signaling an event, like StopIteration for
file reading.  That makes sense, although it does suggest the name
breaks the naming scheme Guido suggested.  But I am not crazy enough
to try to suggest a name change at this point.  =)

> 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.
> 

Well, PendingDeprecationWarning is barely used in Lib/ it seems.  That
would suggest the grouping isn't worth it just because the need to
catch it will be miniscule.  That also kills the argument that it
would simplify warnings filters by cutting down on needing another
registration since the chance of that happening seems to be
microscopic.

> 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.
> 
[SNIP]
> 
> 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).
> 

Now those are two arguments I can go with.

OK, so your points make sense.  I will wait until Monday evening after
work to make any changes to give people a chance to argue against
them, but VMError and AnyDeprecationWarning can be considered removed
and EOFError will be moved to inherit from EnvironmentError again.

Luckily you didn't say you hated TerminalException.  =)

-Brett