RetroSearch Browse

Sat Aug 6 01:18:09 CEST 2005 · http://mail.python.org/pipermail/python-dev/2005-August/055184.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2005-August/055184.html below:

[Python-Dev] Exception Reorg PEP checked in