On 8/4/05, James Y Knight <[EMAIL PROTECTED]> 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 _______________________________________________ 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
