On 7/30/05, Nick Coghlan <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
