Type checking in python?

[Samuel Scarano]

(First of all, I just wanted take a moment to thank Paul Prescod for his
very informative response to my post in this thread.)

Donn Cave wrote:
[snip]
> What about the file object and StringIO?  I mean, supposing that you were
> motivated to implement a class like StringIO, and that the file object
> were also a Python class, would you make StringIO a subclass of file, or
> just implement the interface?
> 
> I would just implement the interface, just because there's nothing of
> value for me (that I can think of, anyway) in the file implementation.
> I want something that ``walks like a duck'', but is not a natural duck
> of some exotic species but a completely unrelated thing that shares only
> its very simple abstractions.  If I carried along a natural duck in
> there, it would be kind of an ancestor fetish, not a useful thing.

Fair enough. I agree that implementing the necessary methods is the most
practical solution in this case -- and in many others. However, I think that
the obvious objection to this approach would be that because there *are* no
explicit interfaces in python, you can't create a class that's guaranteed to
work wherever another class works just by implementing the same methods. It
all seems rather sloppy to me, but I guess that's what you have to live with
in a non-typesafe language. After all, "if you want typesafety, you know
where to get it", right? :-)

> Maybe both should inherit from some class that represents the basic
> notions that they all implement, even though there wouldn't be any
> actual implementation at that level of abstraction, just so's we
> could look at the class hierarchy and say ``It's a duck!''.  I guess
> some languages do this, Python doesn't.  I think that's good.  Because
> we don't respect the ancestor fetish, I don't have to go back to the
> author of file and say ``Hey, why don't you pull an abstract base class
> up out of your class so I can inherit from it?'' and then to the author
> of some library function and say ``Hey, we have this new abstract base
> class for "file", so expect that instead and I can use your function.''
> I just bolt on the duck stuff and we're ready to go in 10 minutes.

Yes, well, my response to this would be that the author should have provided
a distinct interface and implementation in the first place. As Paul Prescod
pointed out, that's the way it works in sather -- and how it *can* work in
java. It would be nice if python provided a means to do this, but then it
wouldn't be python anymore, would it? :-)

Anyway, I now understand that Python really just doesn't provide any
interface mechanism, and that one should not consider the class system to
serve this purpose in any capacity (as I once did) -- it is only for the
purpose of code re-use. From this perspective, the language design and the
programming style it encourages make a lot more sense.

-- 
Samuel R. Scarano                        "Due to circumstances beyond my
undergraduate, Cornell University        control, I am master of my fate
<srs25 at cornell.edu>                      and captain of my soul."
http://people.cornell.edu/pages/srs25/             -- Ashleigh Brilliant