Home Original page

Are there 'Interfaces' in Python??

Titus Brown t at chabry.caltech.edu
Sat Sep 29 04:19:24 EDT 2001 
In article <kd80p9.59n.ln at 10.0.0.1>, Carl Banks  <idot at vt.edu> wrote:
>Titus Brown <t at chabry.caltech.edu> wrote:
>> 
>> 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.

A large part of my objection is based on the fact that the author
of rfc822 (and I realize I'm unfairly maligning them; it's just the
object that had 'tell' had 'seek'... which broke when passed an fo
that had one but not the other ;).  This only happened later on in
the code & resulted in an error being raised in an unexpected routine.
 
Interfaces (or better, signatures, as you describe below) seem to
have the advantage of being up-front about checking requirements,
rather than being a bit lacksadaisical about when requirements are
checked.

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

...Python library documentation?

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

[ munch ]

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

I like the idea -- and at least now I have something to call the constructs
in my own code!  Can you give me an example of a language that uses them?

Learn something every day... ;)

cheers,
--titus
More information about the Python-list mailing list