Are there 'Interfaces' in Python??

[Carl Banks]

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
>>behavior.
> 
> 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 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.

One definition does not work for all stream objects, because different
streams have different capabilities.  Not all streams are seekable,
but if your file-like interface mandates seek and tell methods, you
have to include seek and tell methods with your object.  The readline
method does not make sense for some input streams (for example, a
stream producing random bits).  But if your interface requires a
readline method, then you have to add one.  And if your interface is
minimal, only requiring a couple core methods, how will higher-level 

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
luck, then.


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.


-- 
CARL BANKS