[Python-Dev] Re: *very* revised proposal for interfaces

[Gerald S. Williams]

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