Ok. I think we have identified two sorts of restrictions on the
sorts of adaptations one may want to have:
`stateless' the adaptation may only provide a result which
does not maintain its own state
`lossless' the adaptation preserves all information available
in the original object, it may not discard state
If we determined that these were the 'big-ones', we could possibly
allow for the signature of the adapt request to be parameterized with
these two designations, with the default to accept any sort of adapter:
adapt(object, protocol, alternative = None,
stateless = False, lossless = False)
__conform__(self, protocol, stateless, lossless)
__adapt__(self, object, stateless, lossless)
Then, Guido's 'Optional Static Typing',
def f(X: Y):
pass
would be equivalent to
def f(X):
X = adapt(Y, True, True)
In other words, while calling adapt directly would allow for any adapter;
using the 'Static Typing' short-cut one would be asking for adapters
which are both stateless and lossless. Since __conform__ and __adapt__
would sprout two new arguments, it would make those writing adapters
think a bit more about the kind of adapter that they are providing.
Furthermore, perhaps composite adapters can be automatically generated
from 'transitive' adapters (that is, those which are both stateless
and lossless). But adaptations which were not stateless and lossless
would not be used (by default) in an automatic adapter construction.
Your thoughts?
Clark
--
Clark C. Evans Prometheus Research, LLC.
http://www.prometheusresearch.com/
o office: +1.203.777.2550
~/ , mobile: +1.203.444.0557
//
(( Prometheus Research: Transforming Data Into Knowledge
\\ ,
\/ - Research Exchange Database
/\ - Survey & Assessment Technologies
` \ - Software Tools for Researchers
~ *
_______________________________________________
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
