[Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[Nick Coghlan]

Brett Cannon wrote:
> Nick, are you going go start subbing in for Tim when he is busy and
> take my work that I spent hours on, come up with an alternative that
> took 10 minutes, and have everyone end up loving your newfangled idea
> 10x more than my original?  =)

It's like editing creative writing - I find it far, far easier to take 
something good and tweak it to make it better, than to come up with something 
good in the first place ;)

>>+-- Exception (formerly StandardError)
>>     +-- AssertionError
>>     +-- AttributeError
> 
> 
> I am still up for moving AttributeError, but with the amount of
> arguing going on between where it should go I am not going to be
> shocked if we go with the status quo.

Exactly my thought. I had it under "NameError" for a while, but had difficulty 
coming up with a case where lumping it in with the lexical scoping errors was 
actually beneficial.

Eventually, the fact that it is easy to add another exception to an except 
clause, but hard to remove a child you don't want that inherits from a parent 
you do want persauded me to leave this one alone.

>>     +-- EnvironmentError
>>         +-- OSError
>>             +-- WindowsError (possibly remove this from builtins)
> 
> 
> If we are going to lack exceptions for other OSs, I say remove it.  No
> reason Windows should get special treatment with a built-in exception.

True. And the interface looks the same as the normal OSError interface, so it 
should be possible to replace all uses with a basic OSError.

>>     +-- NameError
>>         +-- UnboundLocalError
> 
> 
> What about UnboundGlobalError?

I realised this was a misnomer. A failed name lookup actually means:
   - the name was not in locals
   - the name was not in any lexically containing scope
   - the name was not in the module globals
   - the name was not in builtins

The program doesn't know which of those namespaces was *meant* to contain the 
name - it only knows that none of them actually contained it. This criticism 
also applies to the current wording of the NameError text used in this 
situation (which implies the name should have been in the module globals).

Now, a case could possibly be made for separate errors for cases like the 
following:

   def f():
     global x
     print x # UnboundGlobalError (currently NameError, with usual text)

   def f():
     def g():
       print x
     g() # UnboundFreeVariableError (currently NameError, with specific text)
     x = 1

Like UnboundLocalError, in both of these cases, the name is potentially known 
to the compiler - it simply hasn't been bound to anything yet.

>>     +-- RuntimeError
> I still don't like the name.

I'm not that fond of it either - but as the builtin exception most likely to 
be used (abused?) by user code, I expect changing its name would be more pain 
than it's worth.

>>         +-- NotImplementedError
> Interesting idea, but I don't view them as the same.  Everyone uses
> RuntimeError as a Poor Man's Exception, not as an actual runtime
> error.

This particular inheritance is copied from Python 2.4 :)

I find the main trick with making RuntimeError more palatable is to avoid 
thinking of 'runtime' in the sense of 'Python runtime', as in 'Python VM'. 
That's not what this error is about - a Python VM error is a SystemError. 
Instead, a RuntimeError is a generic application error - something which 
happened during happened at program runtime.

Renaming RuntimeWarning to SemanticsWarning should help with that distinction.

>>+-- Warning
>>     +-- DeprecationWarning
>>     +-- FutureWarning
>>     +-- PendingDeprecationWarning
> 
> 
> Don't like the idea of having DeprecationWarning inherit from
> PendingDeprecationWarning?

Not really. Mainly because I'm not sure which way the inheritance should go - 
I could understand someone wanting to suppress PendingDeprecationWarnings 
without suppressing DeprecationWarnings. On the other hand, there's your 
argument that a 'DeprecationWarning is just a PendingDeprecationWarning with a 
shorter timeframe'.

Again, I fell back on the concept that Python's except clause makes it easy to 
ask for both if you want both, but makes it relatively difficult to undo 
exception inheritance if it isn't what you want.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com