On Fri, Jan 14, 2005 at 12:11:10AM -0500, Phillip J. Eby wrote:
| 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.
1. Following Raymond's idea for allowing adaption to reflect more
arbitrary properties (which can be used to provide restrictions
on the kinds of adapters expected):
adapt(object, protocol, default = False, **properties)
Request adaptation, where the result matches a set of
properties, such as 'lossless', 'stateless'.
__conform__(self, protocol, **properties)
__adapt__(self, object, **properties)
Conform/adapt but optionally parameterized by a set of
restrictions. The **properties can be used to inform
the adaptation.
register(from, to, adapter = None, predicate = None)
Register an adaptation path from one protocol to another,
optionally providing an adapter. If no adapter is provided,
then adapt(from,to,**properties) is used when adapting. If
a predicate is provided, then the adaptation path is
available only if predicate(**properties) returns True.
2. Perhaps if we just provide a mechanism for an adapter to specify
that it's OK to be used "implicitly" via the declaration syntax?
def fun(x: Y):
...
is equivalent to,
def fun(x):
x = adapt(x, Y, declaration = True)
On Thu, Jan 13, 2005 at 05:52:10PM -0800, Guido van Rossum wrote:
| This may solve the current 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).
Ideally, yes. However, some adapters may want to explicitly disable
their usage in this context -- so some differentiation is warranted.
This 'revised' proposal puts the burden on the adapter (or its
registration) to specify that it shouldn't be used in this context.
I'm carefully using 'declaration' as the restriction, not 'stateless'.
One may have a stateful adapter which is most appropriate to be used
in declarations (see Armin's insightful post).
Furthermore, the 'full' version of adapt() where argument 'restrictions'
can be specified could be done via a decorator syntax:
@adapt(x, Y, **properties)
I hope this helps.
P.S. Clearly there is much of information to be captured in this
thread and put into the PEP (mostly as appendix material); keep
posting good ideas, problems, opinions, whatever -- I will summarize
over this weekend.
--
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
