Are there 'Interfaces' in Python??

[Titus Brown]

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
>>>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 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:

--
try:
   fp.tell()
except:
   has_tell = 0
--

>One definition does not work for all stream objects, because different
>streams have different capabilities.
> [ munch of many thoughtful points ]

Granted.

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

Also granted.

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

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.

cheers,
--titus