Are there 'Interfaces' in Python??
t at chabry.caltech.edu
Thu Sep 27 08:00:37 CEST 2001
In article <k50uo9.m0m.ln at 10.0.0.1>, Carl Banks <idot at vt.edu> wrote:
>Titus Brown <t at chabry.caltech.edu> wrote:
>> In article <dqvso9.rgl.ln at 10.0.0.1>, Carl Banks <idot at vt.edu> wrote:
>>>IMHO, ***THE*** best thing about Python is that inheritance and
>>>interfaces and other such tricks are not required to get polymorphic
>> 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...
>You are correct in saying that there are downsides. I have no
>objection to your claims that StringIO's lack of readlines, and
>rfc822's problem with seek and tell (ignoring, for the moment, that
>the presence of input routines in rfc822 is a design flaw), are much
>more likely in Python because of the lack of interfaces.
I have to say I don't much like the rfc822 code, meself ;).
>I will, however, accept your challenge to answer whether a file-like
>object should include a readlines method. I say it should, if
>readlines makes sense for that type of object. If readlines doesn't
>make sense, then it shouldn't.
Then *how the heck* do you write distributable library code for doing
such things, without resorting to the (fairly hacked) style of rfc822,
which does something along the lines of:
has_tell = 0
>One definition does not work for all stream objects, because different
>streams have different capabilities.
> [ munch of many thoughtful points ]
>And if your interfaces are arranged hierarchially, problems mulitply.
>Now, you have to provide an interface for every possible perumation of
>methods. In other words, you'll have interfaces like
>SeekableButNotReadlineableInputFileStream. And what's to prevent some
>bozo from requiring a SeekableInputFileStream, but without actually
>using the seeking methods? (I've seen, and probably written, Java
>methods that ask for a BufferedInputStream, when I might not want to
>use a buffered stream.)
>And what happens when you wake up one day and suddenly decide a
>file-like object should have a close method, which it didn't before?
>Add the close method to your interface, and, oops, you've just broken
>all types that had implemented that interface.
>And what happens when you want to create a blaug-like object? The
>blaug, like many objects, is not an abstract interface. You're out of
>No thank you. I think the idea that we need to have one definitive
>definition for a file-like object (or any class of objects) is not
>that useful. Statically-typed languages need interfaces to get the
>polymorphic behavior, and interfaces should be viewed as a necessary
>mechanism to accomplish that, not as a good way to organize types.
Good points, all.
It sounds like we'd agree on two things:
* authors of reuse-intended code (something that Python is especially good
for expressing, IMHO) need to lay out some simple assert statements
indicated what the various parameters are;
* even *with* interfaces, there's no guarantee that specific functions
-- e.g. 'readline' -- are going to behave the way you, the author
of the implementation of a function that requires an object
implementing that interface, think they should. So interfaces
may give you a false sense of security if used for type checking,
because they specify arguments, but not behavior.
More information about the Python-list