[Python-Dev] RE: PEP-317

[Guido van Rossum]

> Greg Ewing:
> > Also while we're at it, how about storing the traceback in the
> > exception object, and getting rid of sys.exc_info() etc.?
> 
> Guido:
> > That's a good idea, and I'd support a PEP on that topic more than PEP
> > 317 (which IMO is unnecessary).

Michael Chermside:
> IMO the biggest advantage of PEP 317 is not what it does directly but the
> future enhancements it allows. If all exceptions really are objects, 
> (particularly if strengthened to say "instances of Exception or subclasses")
> then we can add new features to Exception. Moving the traceback into
> the object is one idea. Making Exception a new-style object is another
> (no need to rush, but it'll happen SOMEDAY, right?). Exception
> chaining (aka exception masking) is another.
> 
> The point is, without PEP 317, you can't do these things, because sometimes
> you use an object, and sometimes just mention a class (and sometimes just
> use a string). PEP 317 choose not to try to bite off anything bigger than
> fixing this so future enhancements would be possible. But we EVER want
> these kinds of enhancements, then start a PEP 317 style migration NOW,
> because degree of code breakage means that the migration time will be really
> slow. Deprecating (ideally with warnings) sooner is better.

There seem to be lots of different things in that PEP (I've got no
time to read it in full).

- deprecating string exceptions: definitely

- making all exceptions derive from Exception: most probably

- making Exception a new-style class: eventually

But I'm not at all happy with the proposed deprecation of

  raise Class

and

  raise Class, arguments

in favor of

  raise Class()

and

  raise Class(arguments)

I don't see how this change is necessary in order to get any of the
other benefits.

I also don't understand the commotion over deferred exception
instantiation, since it doesn't happen except for exceptions
raised from C code.

--Guido van Rossum (home page: http://www.python.org/~guido/)