Are there 'Interfaces' in Python??

[Carl Banks]

Titus Brown <t at chabry.caltech.edu> wrote:
> In article <k50uo9.m0m.ln at 10.0.0.1>, Carl Banks  <idot at vt.edu> wrote:
>>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
> --


I wouldn't call the above style "hacked"; it seems to be the logical
way to handle the case where you want to use a feature if it's there,
but continue to work if it's not there (again, notwithstanding that
the presence of input routines in rfc822 is itself a design flaw).

Consider the alternative.  Say we have two interfaces, InputStream and
SeekableInputStream.  Which one does rfc822 support?  If it supports
InputStream, then it can work with pretty much any input-file-line
object, but it can't use seek and tell.  If it supports
SeekableInputStream, then the types of input-file-like objects it can
work with is limited.

And, if we decide that any file-like-object should have seek and tell
methods, what do we do with a nonseekable stream?  rfc822 would invoke
seek and something undefined would happen.  We have to tell rfc822
that seek and tell are not defined for this stream, so we add a
seekable method that returns true if the stream is seekable.  So now
rfc822 makes sure to check whether the stream is seekable before using
seek and tell.  So, what have interfaces given us in this case?
Nothing but added complexity: we still have the same "fairly hacked"
style in rfc822 that we had before.


To answer your question, and I realize I'm being idealistic here, the
way to create distributed library code is for everyone to adhere to
the conventions of what a file-like-object is.

And I do agree that there should be some reference for what that
convention is.  (For file-like object, I'd say use the )



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


Some statically-typed languages have an interesting alternative that's
sort of a compromise between interfaces and open objects: signatures.
g++ supports them as an extension, and other languages have similar
features.

Basically, you define the signature (much like you define an
interface), but you don't declare that your class matches the
signature.  Rather, you create a signature pointer, which can only
point at objects that match the signature.  If you try to point it at
an object that doesn't match the signature, the compiler can detect it
and signal an error.

I don't know how that would work in Python, though.


-- 
CARL BANKS