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

[Brett Cannon]

On 7/30/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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 ;)
>

You stand on the shoulder of a giant (and I am only partially kidding;
people who have met me will get the joke)!
 
> >>+-- 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.
> 

I think this one will require BDFL pronouncement to be moved since
this already looks like a contested idea.  And I don't think Guido is
going to care enough to want to see it moved.

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

Glad you agree.  =)

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

That was what I was thinking as the use case for UnboundGlobalError. 
Also, if you read the docs on NameError, it explicitly states that it
is for global names that are not found.

I am willing to toss in an exception for the failure to find a free
variable (although I would call it UnboundFreeError) to flesh this
namespace hierarchy out.

Then again you could argue you should inherit from each other since a
missing local is kind of lack missing the global namespace as well,
but that kind of purity just doesn't work for me in this case.

[rest of my response to this email is forthcoming]

-Brett