On 11/24/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Thinking about my own example some more, I think it would actually
> work just as well using ABCs instead of abilities. ... It seems the use
> case for making abilities/interfaces separate from ABCs hinges on
> the assumption that there are classes that implement certain
> protocols without realizing it, IOW emergent
> protocols, plus that it's not practical to change __bases__.
In some cases, the interface might require slight adaptation, such as
aliasing a function. But that is something which can be handled
better by adding a new base class.
> I wonder if a bunch of well thought-out standard ABCs, applied to the
> standard data types, and perhaps more support for setting __bases__,
> wouldn't address most concerns.
I think so. A couple thoughts:
The problem with setting bases (other than extension classes) is
largely a style issue -- it can be done now. The code for setting
bases even has comments suggesting how to speed it up, but saying that
it isn't worth it because bases shouldn't change much.
It might be worth adding an __interfaces__ that gets searched after
__bases__. The distinction would indicate that an interface is
lightweight, may change, and (for security and efficiency) cannot
override existing methods. I couldn't change the builtin
str.__contains__, but I could add myproto to str.__interfaces__, and
then I could make calls to "asdf".__interfaces__.myproto.__contains__
for arbitrary strings.
I'm not sure that adding it to the builtin (but in a new name) would
really buy much over an adapter (x in MyProto("asdf") ), but the
interface fans may feel differently.
-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
