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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
_______________________________________________
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
