[Python-Dev] RE: PEP-317

[Guido van Rossum]

> Guido van Rossum:
>   [...]
> > There seem to be lots of different things in that PEP (I've got no
> > time to read it in full).

[Steven T]
> Not so many, actually.  Here's the extreme summary:
> 
>     Implicit instantiation sucks.  Here's how to get rid of it.  Oh,
>     and I can't be bothered to work out how to keep string exceptions
>     when this change is made, so let's get rid of them too.  Let's do
>     this in 3.0 and put warnings in 2.4.

I've now read the PEP, and it simply fails to explain why implicit
instantiation sucks so badly as to require all this pain.  The
arguments of readability and consistency are pretty mild suckage IMO.

[...]
> Afaik the only possibility there is that implicit instantiation
> might be an obstacle to new-style exceptions.  But equally it
> might not be.

It would be simple enough to introduce new-style exceptions if
Exception were made a new-style class and at the same time all
new-style exceptions were required to derive from Exception:

  raise x

would check whether x was:

  - a string (but not an instance of a true subclass of str)
  - a classic class
  - an instance of a classic class
  - Exception or a subclass thereof
  - an instance of Exception or of a subclass thereof

Where the first three cases are for backward compatibility.

Similarly, the rule for

  raise x, y

should allows x to be

  - a string
  - a classic class
  - Exception or a subclass thereof

and in the last two cases, y could either be an instance of x (or of a
subclass of x!), or an argument for x, or a tuple of arguments for x.

> Details:
> 
> Early in the c.l.py discussions which provoked this PEP, it was
> suggested that 'raise' would not be able to distinguish new-style
> instances from new-style classes, and so would not be able to
> decide reliably whether to instantiate implicitly.  If this were
> true, implicit instantiation would have to be eliminated in order
> to allow new-style exceptions in the future.
> 
> However, there seem to be at least two alternative solutions for
> this problem:
> 
>     1. Make inheritance from Exception mandatory, and test
>         if issubclass(firstarg, Exception): treat like class
>         elif isinstance(firstarg, Exception): treat like instance
>         else: blow up
>     (There are also other reasons for wanting mandatory inheritance
>     from Exception, but they don't relate to implicit instantiation in
>     any way.)
> 
>     2. Test
>         if isinstance(firstarg, type): treat like class
>         else: treat like instance
>     (This assumes string exceptions are long gone.)

Right.  Either is better than the draconian solution from PEP 317.

> Eliminating implicit instantiation definitely does away with the
> problem entirely; it may be that one or both of the above
> alternatives would suffice as well, though that is less clear to
> me.  (Opinions solicited!)

ATM I'm inclined to require deriving from Exception, allowing classic
classes (and even strings) for backwards compatibility as stated above.

> > I also don't understand the commotion over deferred exception
> > instantiation, since it doesn't happen except for exceptions
> > raised from C code.
> 
> Apparently Pyrex uses the Python syntax for the C semantics.

Well, Pyrex is its own language, even though it resembles Python.

> Eliminating the implicit instantiation syntax from Python would
> make Pyrex weirder for Python programmers.  (I do wonder whether
> that would be a good thing, given that the semantics are actually
> different.)

Pyrex is weird enough already; this quirk wouldn't be hard to document
and has to be documented anyway.

> Afaik that's the only concern related to deferred instantiation.

Not quite. :-)

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