On 8/4/05, Nick Coghlan
Since I forgot to mention it in the last couple of messages - this version looks very good. The transition strategy section makes it a lot more meaningful.
Great to hear!
Brett Cannon wrote (in the PEP):
Renamed Exceptions
Renamed exceptions will directly subclass the new names. When the old exceptions are instantiated (which occurs when an exception is caught, either by a try statement or by propagating to the top of the execution stack), a PendingDeprecationWarning will be raised.
Nice trick with figuring out how to raise the deprecation warning :) (That line was going to read 'Why not just create an alias?', but then I worked out what you were doing, and why you were doing it)
Thanks.
One case that this doesn't completely address is NameError, as it is the only renamed exception which currently has a subclass. In this case, I think that during the transmition phase, all three of the 'Unbound*Error' exceptions should inherit from NameError, with NameError inheriting from NamespaceError.
I believe it should still be possible to get the deprecation warning to work correctly in this case (by not raising the warning when a subclass is instantiated).
Ah, didn't think about that issue. Yeah, as long as you don't call a superclass' __init__ it should still work.
In the 'just a type' category, WeakReferenceError should still be under StandardError in the hierarchy.
Yeah, that is an error from trying adding StandardError back in. -Brett