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