PEP 317: Eliminate Implicit Exception Instantiation

Beni Cherniavsky cben at techunix.technion.ac.il
Mon Jun 9 13:47:45 EDT 2003


Bernhard Herzog wrote on 2003-06-09:

> Steven Taschuk <staschuk at telusplanet.net> writes:
>
> [...]
> > Specification
> > =============
> >
> > The syntax of ``raise_stmt`` [3]_ is to be changed from ::
> >
> >     raise_stmt ::= "raise" [expression ["," expression ["," expression]]]
> >
> > to ::
> >
> >     raise_stmt ::= "raise" [expression ["," expression]]
> >
> [...]
> > Warnings
> > ''''''''
> [...]
> > The third warning is issued when a ``raise`` statement with three
> > expressions is compiled.  (Not, note, when it is executed; this is
> > important because the ``SyntaxError`` which this warning presages will
> > occur at compile-time.)  The message for this warning is::
> >
> >     raising with three arguments will be impossible in the future
> >
> > These warnings are to appear in Python 2.4, and disappear in Python
> > 3.0, when the conditions which cause them are simply errors.
>
> How do I write code that raises and exception with an explicit traceback
> object that works both with Python 2.4 and at least 2.3 (preferably 2.2
> and 2.1 as well) and that does not issue warnings?
>
Good question.  Why not autodetect this?  Currently__:

    If the first object is an instance, the type of the exception is
    the class of the instance, the instance itself is the value, and
    the second object must be None.

    __ http://www.python.org/dev/doc/devel/ref/raise.html

So if it's already an instance and there are two objects and the
second object is not None, let's treat it as a traceback.  More magic,
less hassle.  Wait, we wanted less magic - but this is OK <wink>.  I
even propose this part to be put into 2.3.

This reminds us of the question what is an instance.  This is hard to
define with new-style classes but "anything that is not callable" is a
good definition (because if it's a class we want to call it anyway).
When this PEP will be executed completely, this question can be
dropped because the first object will be assumed to always be an
instance.

-- 
Beni Cherniavsky <cben at users.sf.net>





More information about the Python-list mailing list