On Apr 1, 2006, at 10:52 AM, Tim Hochberg wrote:
...
> overengineered examples that make my brain lock up. Someone who knows
> something about adapters needs to go off and come up with the worlds
> simplest, most light weight, dumb as a post, adapter proposal. It may
Heh, funny -- that's basically what I tried to do in my post,
composed no doubt at the same time you were composing this; and my
"proposal" (more of an "explanation", really) shares many aspect with
yours, such as the concept of protocol/descriptions being somewhat
arbitrary (but hashable) "tags" relying entirely on conventions
(human readable descriptions of constraints) without enforcement.
> I'm assuming that sticking the above six lines in a file somewhere
> wouldn't be sufficient for some reason, but if not, why not? And
> what's
> the simplest possible proposal that would work?
The simplest possible proposal that would do some good would look
very similar to yours, and mine, net of minor factoring issues. If
adaptation was available in Python's standard library and used
reasonably widely within it, that would kickstart its wide adoption.
I'm quite ready to discuss the various reasons which make these
levels of proposals/explanatioms not really optimal for real-world
adoption; I mentioned such reasons repeatedly in my post.
For example, we could start with a fundamental inheritance issue: if
there's an adapter registered from type T to protocol P, should I
really register it again if I subclass T into S -- shouldn't S just
inherit the adaptation from T (since that's what's wanted most often,
when inheritance is used in a properly Liskovian way to assert that
each S is-a T), at least as the default behavior, perhaps with the
possibility to override when needed -- by registering a different
adapter specifically from S to P, of course -- perhaps a cannot_adapt
one, such as:
def cannot_adapt(*whocares):
raise CannotAdaptError
If "inheritance of adaptation" is desired, it can be done in at least
two ways: by having adapt loop on the MRO and checking each, or by
having the metaclass look for all adapters of bases and registering
what it finds. The first strategy might be augmented by caching/
memoizing: if an adapter is found for some type that's in the MRO but
not in first place, before returning it, adapt could explicitly
register that so that future lookups will be much faster. But then
we need to decide what happens to this 'cache' when some different
adapter gets registered for a base type...
Such need to dwell on practical details is not special to adaptation,
of course: if Python didn't have the concept of a mapping and we were
trying to develop one, the development from "cool abstract idea with
a simple-as-dirt reference implementation" to "real-world precious
tool" would be even more torturous;-). We could start with "a list
of key/value pairs" (a ``property list'' kind of thing), then have to
deal with performance issues, uniqueness, handy auxiliary
methods, ...;-).
But the usefulness of adaptation doesn't entirely depend on the ways
all such issues are brought up and resolved... even a dirt-simple
approach would be better than nothing (except perhaps for standing in
the way of future improvements along the various axes -- error-
checking, performance, handiness, ... -- so, the detailed behavior of
such a first-cut, extra-simple approach should probably be carefully
left underspecified, if it were to be adopted, to allow for future
improvements;-).
Alex
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
