Are there 'Interfaces' in Python??
tim at vegeta.ath.cx
Thu Sep 27 00:25:57 CEST 2001
Me parece que Titus Brown <t at chabry.caltech.edu> dijo:
> In article <dqvso9.rgl.ln at 10.0.0.1>, Carl Banks <idot at vt.edu> wrote:
> >tszeto <tszeto at mindspring.com> wrote:
> >> Hello,
> >> Was wondering if Python supported 'Interfaces' (something akin to Java
> >> interfaces)? Or if there's a workaround to get the same thing.
> >IMHO, ***THE*** best thing about Python is that inheritance and
> >interfaces and other such tricks are not required to get polymorphic
> >Take, for example, StringIO objects. They are not syntactically
> >related to File objects in any way: neither is derived from the other,
> >they are not derived from a common base class, and they do not
> >implement a common "official" interface. Yet, because StringIO
> >objects provide the same methods that File objects provide, one can
> >use StringIO object as if they were an ordinary File objects.
> >Basically, if something looks like a File object, and acts like a File
> >object, one can use it like a File object. So, unlike Java, you don't
> >need interfaces to get polymorphic behavior in Python.
> I'm not clear why this is such a GOOD thing. It's not necessarily BAD,
> unless you (for example) have to debug the 'rfc822' module, which assumes
> that any file-like object which has 'seek' must have 'tell', but doesn't
> indicate in any way what the lack of both affects handling, and furthermore
> raises an error if you have one but not the other.
> There's also the mystifying lack of 'readlines' on StringIO objects
> in Python before 2.0. Does a file-object-like-thing have to have
> readlines? Well, they all do now -- how about seek? tell? read() behavior?
> You tell me, after going and looking at all the file-object-like-things
> in the distribution. Oh -- but wait, you can't find them all, because
> they're all unrelated...
> I would rather regard this as neutral & a convenience for people writing
> code that uses file-object-like-things. It's certainly not a convenience
> for people writing new classes that attempt to emulate the behavior of
> already-existing objects with unclear definitions, and it sure would be
> nice to have the option of some type checking built into the language,
> but I understand why it's not there and appreciate the convenience. But
> there are downsides too...
This sounds like one of the many threads in c.l.smalltalk. :)
If you want to use interface-style type checking, the following might
work for you:
class MyIFException(Exception, MyInterface):
# implement and extend
and use isinstance(obj, MyInterface) to see if it implements it.
It doesn't survive someone deleting keys from the o.__dict__ attribute,
but Python's run-time nature precluded that long ago, didn't it?
I'm not an alien. I'm discontent.
-- Stan, "The Faculty"
More information about the Python-list