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.
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)
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).
In the 'just a type' category, WeakReferenceError should still be under
StandardError in the hierarchy.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4