PEP 317: Eliminate Implicit Exception Instantiation

Steven Taschuk staschuk at telusplanet.net
Mon Jun 9 20:21:17 CEST 2003


Quoth Beni Cherniavsky:
  [...]
> 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.

I don't think this meets Bernard's objective, which is to have
traceback-using raise statements which run on all 2.x without
warnings.  Whatever is done with 2.3 (and I doubt at this point
any such change would be accepted), only the three-argument form
will work in <= 2.2, and it is exactly this form for which the PEP
proposes warnings in >= 2.4.

Your suggestion does, however, obviate the need for the future
statement, at the cost of, as you say, more magic during the
transition period.

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

One reason for the PEP, in fact.  (Though only alluded to briefly
in the Motivation section.)

Another approach is to require that exceptions be instances of
Exception.  Then we could do
    if isinstance(first_obj, Exception):
        # first_obj is exception object
    elif issubclass(first_obj, Exception):
        # instantiate implicitly
    else:
        # error
Then eventually Exception could be made new-style without an
instance/class detection problem, I think.

-- 
Steven Taschuk                                                 o- @
staschuk at telusplanet.net                                      7O   )
                                                               "  (





More information about the Python-list mailing list