> +-- 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'
> }
> )
_______________________________________________
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
