[Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0 (original) (raw)

Brett Cannon bcannon at gmail.com
Sun Jul 31 04:15:24 CEST 2005

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

More information about the Python-Dev mailing list