Movatterモバイル変換

[Python-Dev] Exception Reorg PEP checked in

• Previous message:[Python-Dev] Exception Reorg PEP checked in
• Next message:[Python-Dev] Exception Reorg PEP checked in
• Messages sorted by:[ date ][ thread ][ subject ][ author ]

>        +-- NamespaceError (rename of NameError)>            +-- UnboundFreeError (new)>            +-- UnboundGlobalError (new)>            +-- UnboundLocalError>What are these new exceptions for? Under what circumstances are they  raised? Why is this necessary or an improvement?> 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.>> This should properly preserve backwards-compatibility as old usage> won't change and the new names can be used to also catch exceptions> using the old name. The warning of the deprecation is also kept> simple.This will cause problems when a library raises the exception under  the new name and an app tries to catch the old name. So the standard  lib (or any other lib) cannot raise the new names. Because the stdlib  must raise the old names, people will see the old names, continue  catching the old names, and the new names will never catch on.Perhaps it'd work out better to have the new names subclass the old  names. Then you have to continue catching the old name as long as  anyone is raising it, but at least you can raise the new name with  impunity. I expect not much code actually raises ReferenceError or  NameError besides that internal to python. Thus it would be  relatively safe to change all code to catch the new names for those  immediately. Lots of code raises RuntimeError, but I bet not very  much code explicitly catches it.Oh, but if the stdlib starts raising under the new names, that'll  break any code that checks the exact type of the exception against  the old name. Boo.It'd be better to somehow raise a DeprecationWarning upon access, yet  still result in the same object. Unfortunately I don't think there's  any way to do that in python. This lack of ability to deprecate  module attributes has bit me several times in other projects as well.  Matt Goodall wrote the hack attached at the end in order to move some  whole modules around in Nevow. Amazingly it actually seemed to  work. :) Something like that won't work for __builtins__, of course,  since that's accessed directly with PyDict_Get.All in all I don't really see a real need for these renamings and I  don't see a way to do them compatibly so I'm -1 to the whole idea of  renaming exceptions.> Removal of Bare except Clauses>> A SemanticsWarning will be raised for all bare except clauses.Does this mean that bare except clauses change meaning to "except  Exception" immediately? Or (I hope) did you mean that in Py2.5 they  continue doing as they do now, but print a warning to tell you they  will be changing in the future?James> import sys> import types> import warnings>> from twisted.python import reflect>> class ModuleWithDeprecations(types.ModuleType):>>     def __init__(self, original, deprecatedNames):>         self.original = original>         self.deprecatedNames = deprecatedNames>>     def __getattr__(self, name):>         newName = self.deprecatedNames.get(name, None)>         if newName is not None:>             warnings.warn("nevow.%s is deprecated, please import %s> instead!"% (name,newName), DeprecationWarning, 2)>             return reflect.namedAny(newName)>         return getattr(self.original, name)>> # Evil hack? What evil hack!> sys.modules['nevow'] = ModuleWithDeprecations(>     sys.modules['nevow'],>     {'formless': 'formless',>      'freeform': 'formless.webform'>      }>     )

• Previous message:[Python-Dev] Exception Reorg PEP checked in
• Next message:[Python-Dev] Exception Reorg PEP checked in
• Messages sorted by:[ date ][ thread ][ subject ][ author ]