[Python-Dev] Re: very revised proposal for interfaces (original) (raw)

Gerald S. Williams gsw@agere.com
Wed, 2 Oct 2002 17:31:08 -0400

John Williams wrote:

I think we're trying to solve different problems. You seem to want to very that a class supports a certain set of methods, but I just want to verify that the class claims to implement the interface and provide a framework to make that happen, like a more automated version of PEP 245.

They're aspects of the same problem. When the claim is made, it should be verified to some degree in case the interface changes out from beneath the implementer (to what degree is certainly negotiable, though).

Checking for late binding and generally anything other than the presence of unbound class methods requires an object, although it can still be done. Or you could have ways to explicitly mark these as supported (perhaps a parameter to the implemented_by method in my example).

This only works when you can add methods to classes that implement the interface. It's a bit awkward for retrofitting classes you didn't write, and just not possible for classes implmented in C, like the builtin classes.

No matter what you have under the hood, you should at least be able to wrap it entirely. My point is that if you want to provide a new interface, just do it with existing mechanisms. (If there are cases where this isn't possible, adding a way to define class-type interfaces that cannot be expressed now seems wrong to me.)

> I think we're both saying the same thing [ ... ] I think we're more in agreement than you think.

Yes, we're in violent agreement. :-) Well, at least we're converging...

Actually, there is still one sticking point: the presence of wrappers and proxys. IMO, mechanisms exist to implement these if needed, so I'd rather leave them out (and consequently not have to change the Python language at all).

-Jerry