[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