[Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0

Brett Cannon bcannon at gmail.com
Thu Aug 4 00:47:54 CEST 2005

On 8/3/05, James Y Knight <foom at fuhm.net> wrote:
> On Aug 3, 2005, at 3:00 PM, Guido van Rossum wrote:
> > [...brain hums...]
> >
> > OK, I'm changing my mind again about the names again.
> >
> > Exception as the root and StandardError can stay; the only new
> > proposal would then be to make bare 'except:' call StandardError.
> I don't see how that can work. Any solution that is expected to
> result in a usable hierarchy this century must preserve "Exception"
> as the object that user exceptions should derive from (and therefore
> that users should generally catch, as well). There is way too much
> momentum behind that to change it.

Oh, I bet Guido can make them change.  =)

Look at it this way; going with the Raisable/Exception change and
having bare 'except's catch Exception will still lead to a semantic
change since CriticalError and ControlFlowException will not be
caught.  Breakage is going to happen, so why not just do a more
thorough change that leads to more breakage?

Obviously you are saying to minimize it while Guido is saying to go
for a more thorough change.  So how much more code is going to crap
out with this change?  Everything under our control will be fine since
we can change it.  User-defined exceptions might need to be changed if
they inherit directly from Exception instead of StandardError, which
is probably the common case, but changing a superclass is not hard. 
That kind of breakage is not bad since you can easily systematically
change superclasses of exceptions from Exception to StandardError
without much effort thanks to regexes.

I honestly think the requirement of inheriting from a specific
superclass will lead to more breakage since you can't grep for
exceptions that don't at least inherit from *some* exception


More information about the Python-Dev mailing list