On 8/4/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > 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 _______________________________________________ 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
