> > > > > +-- 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?
[James Y Knight] > > > 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 [Raymond] > > Do we have any use cases for making the distinctions. I have NEVER had > > a reason to write a different handler for the various types of > > NameError. > > > > Also, everyone knows what a Global is. Can the same be said for Free? > > I had thought that to be a implementation detail rather than part of the > > language spec. [Brett] > Perhaps then we should just ditch UnboundLocalError? Perhaps the hierarchy should be left unchanged unless there is shown to be something wrong with it. "just ditching" something is not a rationale that warrants a language change. What problem is being solved by making additions or deletions to subclasses of NameError? > If we just make > sure we have good messages to go with the exceptions the reasons for > the exception should be obvious. +1 Raymodn _______________________________________________ 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
