[Python-ideas] ABC: what about the method arguments ?

[Antoine Pitrou]

Le jeudi 23 septembre 2010 à 20:59 +0200, Tarek Ziadé a écrit :
> 
> That's fine indeed. Now, why wouldn't the implementor of an
> application use ABC to check that the third party class he's about to
> load in his app implements the desired ABC?

Why would he? What does it provide him exactly? A false sense of
security / robustness?

> > Also, why do you think checking signatures is actually useful? It only
> > checks that the signature is right, not that the expected semantics are
> > observed. The argument for checking method signature in advance is as
> > weak as the argument for checking types at compile time.
> 
> Sorry but it seems that you are now advocating against ABC altogether.

As I said, I believe ABCs are useful mainly for documentation purposes;
that is, for conveying an /intent/.
Thinking that ABCs guarantee anything about quality or conformity of the
implementation sounds wrong to me.

(the other reason for using ABCs is to provide default implementations
of some methods, like the io ABCs do)

> This is completely orthogonal to the discussion which is: extend a
> method checker to check attributes.

It's not really orthogonal. I'm opposing the idea that programmatically
checking the conformity of method signatures is useful; I also think
it's *not* a good thing to advocate to Python programmers coming from
other languages.

> In that case I am curious to see why you would have file I/O method
> with extra *args/**kwargs.

def seek(self, *args):
    return self.realfileobj.seek(*args)

> So are you in favor of the removal of all kind of type checking
> mechanism in Python ?

"Type" checking is simply done when necessary. It is duck typing.
Even in the case of ABCs, method calls are still duck-typed. For
example, if you look at the io ABCs and concrete classes, a
BufferedReader won't check that you are giving it a RawIOBase to wrap
access to.

Regards

Antoine.