[Python-Dev] Exception Reorg PEP checked in

[Brett Cannon]

On 8/4/05, James Y Knight <foom at fuhm.net> wrote:
> >        +-- 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?
>

Exceptions relating to when a name is not found in a specific
namespace (directly related to bytecode).  So UnboundFreeError is
raised when the interpreter cannot find a variable that is a free
variable.  UnboundLocalError already exists.  UnboundGlobalError is to
prevent NameError from being overloaded.  UnboundFreeError is to
prevent UnboundLocalError from being overloaded
 
> > 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.
> 

Crap, you're right.  Going to have to think about this more.

> 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.
> 

Well, the new names can go into 2.x but not removed until 3.0 .

And there is always a solution.  We do control the implementation so
something has evil as hacking the exception system to do
class-specific checks could work.

> > 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?

They would have a warning for a version, and then change.

And this will nost necessarily go into 2.5 .

-Brett