Based on later discussion, it sounds like Alex sees adaptation as
(what I called case 2) -- The caller must make an explict call to
adapt. The advantage of adaption is that somebody other than the
caller or callee can fill in the appropriate code __adapt__ code.
Is this much correct?
If so, I start to see why it hasn't caught on -- it is too wordy, and
arguably too inefficient for the common case.
When I'm writing a new class, I'm already annoyed by translation
functions such as:
def __index__(self):
return long(self).__index__()
but the payoff is that I can write
seq[myinst]
in calling classes. At this point, adaptation sounds like I would
have to write (or count on a 3rd-party to write a more cumbersome
version of)
@implements(IIndex)
def __index__(self):
return long(self).__index__()
Meanwhile, callers would have to write
seq[IIndex(myinst)]
If we were talking only a few large or obscure protocols, this would
be reasonable. If it gets used very often, it will start polluting
code with boilerpate.
If the calling code were moved beneath the covers (so that __getitem__
made the IIndex cast, instead of my code), that would help.
If direct protocol implementations could be auto-discovered, that
would also help, but then we're back to the original question of what
adaptors really add over the present ad-hoc duck typing. Perhaps the
default metaclass could autodiscover a few well-known or legacy
protocols, such as __index__, __iter__, and copy_reg? (And then
you're back to having trouble finding a motivating example...)
-jJ
_______________________________________________
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
