Movatterモバイル変換
[0]ホーム
[Python-Dev] RE: PEP-317
Steven Taschukstaschuk@telusplanet.net
Tue, 10 Jun 2003 17:16:27 -0600
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 eliminatingimplicit instantiation.)> - making all exceptions derive from Exception: most probably> - making Exception a new-style class: eventuallyNeither of these is in the PEP, though as it happens I do supportboth (pending migration plans, naturally). Afaik, these areorthogonal to eliminating implicit instantiation, except possiblyfor 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 instantiationmight be an obstacle to new-style exceptions. But equally itmight not be.Details:Early in the c.l.py discussions which provoked this PEP, it wassuggested that 'raise' would not be able to distinguish new-styleinstances from new-style classes, and so would not be able todecide reliably whether to instantiate implicitly. If this weretrue, implicit instantiation would have to be eliminated in orderto allow new-style exceptions in the future.However, there seem to be at least two alternative solutions forthis 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 theproblem entirely; it may be that one or both of the abovealternatives would suffice as well, though that is less clear tome. (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 wouldmake Pyrex weirder for Python programmers. (I do wonder whetherthat would be a good thing, given that the semantics are actuallydifferent.)Afaik that's the only concern related to deferred instantiation.-- Steven Taschukstaschuk@telusplanet.net"I tried to be pleasant and accommodating, but my head began to hurt from his banality." -- _Seven_ (1996)
[8]ページ先頭