Quoth Guido van Rossum:
[...]
> There seem to be lots of different things in that PEP (I've got no
> time to read it in full).
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.
Btw, I quote you as being in favour of explicit instantiation.
(Though not, I should note, as being in favour of eliminating
implicit instantiation.)
> - making all exceptions derive from Exception: most probably
> - making Exception a new-style class: eventually
Neither of these is in the PEP, though as it happens I do support
both (pending migration plans, naturally). Afaik, these are
orthogonal to eliminating implicit instantiation, except possibly
for one respect, discussed below.
[implicit instantiation itself]
> I don't see how this change is necessary in order to get any of the
> other benefits.
Afaik the only possibility there is that implicit instantiation
might be an obstacle to new-style exceptions. But equally it
might not be.
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.)
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!)
> 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.
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.)
Afaik that's the only concern related to deferred instantiation.
--
Steven Taschuk staschuk@telusplanet.net
"I tried to be pleasant and accommodating, but my head
began to hurt from his banality." -- _Seven_ (1996)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4