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".)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
