[Python-Dev] PEP 246: lossless and stateless
Phillip J. Eby
pje at telecommunity.com
Fri Jan 14 06:11:10 CET 2005
At 05:52 PM 1/13/05 -0800, Guido van Rossum wrote:
>This may solve the curernt raging argument, but IMO it would make the
>optional signature declaration less useful, because there's no way to
>accept other kind of adapters. I'd be happier if def f(X: Y) implied X
>= adapt(X, Y).
The problem is that type declarations really want more guarantees about
object identity and state than an unrestricted adapt() can provide,
including sane behavior when objects are passed into the same or different
functions repeatedly. See this short post by Paul Moore:
http://mail.python.org/pipermail/python-dev/2005-January/051020.html
It presents some simple examples that show how non-deterministic adaptation
can be in the presence of stateful adapters created "implicitly" by type
declaration. It suggests that just avoiding transitive interface adapters
may not be sufficient to escape C++ish pitfalls.
Even if you're *very* careful, your seemingly safe setup can be blown just
by one routine passing its argument to another routine, possibly causing an
adapter to be adapted. This is a serious pitfall because today when you
'adapt' you can also access the "original" object -- you have to first
*have* it, in order to *adapt* it. But type declarations using adapt()
prevents you from ever *seeing* the original object within a function. So,
it's *really* unsafe in a way that explicitly calling 'adapt()' is
not. You might be passing an adapter to another function, and then that
function's signature might adapt it again, or perhaps just fail because you
have to adapt from the original object.
Clark's proposal isn't going to solve this issue for PEP 246, alas. In
order to guarantee safety of adaptive type declarations, the implementation
strategy *must* be able to guarantee that 1) adapters do not have state of
their own, and 2) adapting an already-adapted object re-adapts the original
rather than creating a new adapter. This is what the monkey-typing PEP and
prototype implementation are intended to address.
(This doesn't mean that explicit adapt() still isn't a useful thing, it
just means that using it for type declarations is a bad idea in ways that
we didn't realize until after the "great debate".)
More information about the Python-Dev
mailing list