[Python-3000] interfaces
Antoine Pitrou
solipsis at pitrou.net
Sun Nov 19 11:13:26 CET 2006
Le samedi 18 novembre 2006 à 22:42 -0700, Neil Toronto a écrit :
> Actually, plenty of people would dream of it and even do it. I've seen
> some pretty evil implementations of Java interfaces. All they can
> enforce is static types and method signatures.
But protecting against erroneous use (rather than deliberate misuse) can
be a reasonable goal. There are cases where relying on duck-typing leads
to silent bugs instead of nice explicit tracebacks. Then as the
implementer of the API it is good to be able to enforce some aspects of
the API, so that your users don't lose time finding those bugs.
I had the problem recently when I wrote a decorator which took an
optional number as an argument. The decorator declaration goes like
this:
def deferred(timeout=None):
def decorate(func):
blah blah...
return decorate
It can be used like this:
@deferred()
def test_case():
...
The problem was if you forgot the parentheses altogether:
@deferred
def test_case():
...
In that case, no exception was raised, but the test was silently
ignored. Also, "@deferred" doesn't strike at first sight like something
is missing (parameterless decorators do exist).
So to know if "deferred" was correctly used, I had to devise a test to
know if "timeout" is a number (without mandating that it is a e.g. float
rather than an int). I ended up with this:
try:
timeout is None or timeout + 0
except TypeError:
raise TypeError("'timeout' argument must be a number or None")
Instead of testing "timeout" against an arbitrary arithmetic operation,
it would be more robust to test it against an interface (say "Number").
I think that's the kind of use cases which makes people oppose the idea
of removing callable(). It feels more robust to test against an
interface than against a specific trait of that interface.
More information about the Python-3000
mailing list