[Python-Dev] PEP 246: lossless and stateless (original) (raw)

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