Does Class implements Interface?

[Emanuele D'Arrigo]

Greetings everybody,

let's say I have a Class C and I'd like to verify if it implements
Interface I. If I is available to me as a class object I can use
issubclass(C, I) and I can at least verify that I is a superclass of
C. There are a couple of issues with this approach however:

1) C might override not just I's methods code but also I's methods
signatures, effectively changing the interface.
2) What if I is -not- available to me as the superclass of C but as a
description of the interface, i.e. as an IDL(*) file?

Are there resources such as tools, recipes, documents or strategies
that could help me deal with these issues? I've already looked into
the ABC module and the zope.interface. I'm just fishing for more
things to look at.

Manu

(*) http://en.wikipedia.org/wiki/Interface_description_language

 

[Jonathan Gardner]

Greetings everybody,

let's say I have a Class C and I'd like to verify if it implements
Interface I. If I is available to me as a class object I can use
issubclass(C, I) and I can at least verify that I is a superclass of
C. There are a couple of issues with this approach however:

1) C might override not just I's methods code but also I's methods
signatures, effectively changing the interface.
2) What if I is -not- available to me as the superclass of C but as a
description of the interface, i.e. as an IDL(*) file?

Are there resources such as tools, recipes, documents or strategies
that could help me deal with these issues? I've already looked into
the ABC module and the zope.interface. I'm just fishing for more
things to look at.

Have you heard of duck typing?

Ignore all those things and rely on human (aka natural language)
documentation. That is, if you want to see if a class will work for an
interface, go read the docs on the interface (or rather, what the
function expects the interface to be) and what the class provides and
see if they fit.

 

[Emanuele D'Arrigo]

Have you heard of duck typing?
Yes.

Ignore all those things and rely on human (aka natural language)
documentation. That is, if you want to see if a class will work for an
interface, go read the docs on the interface (or rather, what the
function expects the interface to be) and what the class provides and
see if they fit.

Apologies, my fault, I didn't explain that humans are out of the loop
entirely. It's only at runtime that the program obtains the class
object that might or might not conform to an expected interface. In
fact the program might obtain multiple objects and have to decide
which one conforms best to the expected interface. Of course I could
use hasattr() and the inspect module (anything else?) to find out if
existing attributes and method signatures are those expected. Or I
could just deal with the exceptions as they are raised. However, if I
could somehow rely that the object I'm getting has the right methods
and signatures I could avoid peppering the code with try/except
constructs.

I was just wondering then if this has been somewhat dealt with and has
been wrapped in a neat package, set of functions, recipe or pattern.

Manu

 

[Jonathan Gardner]

Apologies, my fault,

No apology is necessary.

I didn't explain that humans are out of the loop
entirely. It's only at runtime that the program obtains the class
object that might or might not conform to an expected interface. In
fact the program might obtain multiple objects and have to decide
which one conforms best to the expected interface. Of course I could
use hasattr() and the inspect module (anything else?) to find out if
existing attributes and method signatures are those expected. Or I
could just deal with the exceptions as they are raised. However, if I
could somehow rely that the object I'm getting has the right methods
and signatures I could avoid peppering the code with try/except
constructs.

I was just wondering then if this has been somewhat dealt with and has
been wrapped in a neat package, set of functions, recipe or pattern.

Don't bother with introspection using hasattr() and such. Use
exceptions. If the object that is instantiated at run-time doesn't
provide the right interface, throw an exception and direct it to the
responsible party.

This isn't much different than what you'd do if you're writing an app
that expects a string of digits but is instead given a string of non-
digits. Rather than inspecting the string before converting it
(introspection), just try to convert it and catch the exception. Then
handle the exception such that you tell the person who entered the
data, "I wanted numbers, not letters" and allow them to try again.

When you stop asking "Did I get something I expect?" except only when
it is absolutely necessary, then you can get back to writing your
program.

 

[Jonathan Gardner]

Yes.

I was just wondering then if this has been somewhat dealt with and has
been wrapped in a neat package, set of functions, recipe or pattern.

As a joke (but only partly), here's the python code you'd use to check
to see if a value conforms with expectations:

<code>
</code>

As you can see, the above code is not only easy to write, but easy to
write unit tests for, compile, run, and debug. It simply doesn't get
better than this.

 

[Max Landaeus]

Apologies, my fault, I didn't explain that humans are out of the loop
entirely. It's only at runtime that the program obtains the class
object that might or might not conform to an expected interface. In
fact the program might obtain multiple objects and have to decide
which one conforms best to the expected interface. Of course I could
use hasattr() and the inspect module (anything else?) to find out if
existing attributes and method signatures are those expected. Or I
could just deal with the exceptions as they are raised. However, if I
could somehow rely that the object I'm getting has the right methods
and signatures I could avoid peppering the code with try/except
constructs.

I was just wondering then if this has been somewhat dealt with and has
been wrapped in a neat package, set of functions, recipe or pattern.

Manu

Check out Alex Martelli's recipe 'Checking wheter an object has
necessary attributes' in the Python Cookbook:
http://books.google.co.uk/books?id=...cover&dq=python+cookbook#v=onepage&q=&f=false
<http://books.google.co.uk/books?id=...cover&dq=python+cookbook#v=onepage&q=&f=false>

Max

 

[Emanuele D'Arrigo]

Jonathan, Stephen and Max, thank you all for the tips and tricks. Much
appreciated.

Manu

 

[Zvezdan Petkovic]

Are there resources such as tools, recipes, documents or strategies
that could help me deal with these issues? I've already looked into
the ABC module and the zope.interface. I'm just fishing for more
things to look at.

You say above that you looked at zope.interface.
Did you look at zope.interface.verify?
Specifically, verify.txt doctests state that:

"An object provides an interface if

- either its class declares that it implements the interfaces,
or the object declares that it directly provides the interface

- the object defines all the methods required by the interface

- all the methods have the correct signature

- the object defines all non-method attributes required by the
interface"

zope.interface.verify.verifyObject(I, obj) will check all of the above.
Similarly, zope.interface.verify.verifyClass(I, C) will check the class.
It is a good practice to call these functions in the regression tests.

If this is not what you are looking for, sorry for the noise.

Zvezdan