Are there 'Interfaces' in Python??
tszeto
Was wondering if Python supported 'Interfaces' (something akin to Java
interfaces)? Or if there's a workaround to get the same thing.
Thanks,
Ted
Paul Rubin
> Was wondering if Python supported 'Interfaces' (something akin to Java
> interfaces)? Or if there's a workaround to get the same thing.
Java interfaces are a workaround for java's non-support of multiple
base classes in objects. Python supports multiple base classes, so
it doesn't need a workaround for their absence.
Tim Hammerquist
IOW, Python equivalents to Java interfaces are base-classes with virtual
functions, also called "mix-in" classes. eg:
class MyClass:
pass
class MyInterface:
def func1(self):
raise NotImplementedError # force virtual method
class MyInterfacingClass(MyClass,MyInterface):
def func1(self):
pass
HTH
--
Trust the computer industry to shorten the term "Year 2000" to Y2K. It
was this kind of thinking that got us in trouble in the first place.
-- Adrian Tyvand
Richard Jones
Er, no. They may be percieved as that, but since interfaces can't actually
_do_ anything, whereas multiple inheritance _can_, I believe this is a dead
herring.
Interfaces are an extremely useful form of "type" checking for OO systems.
Python already has "interfaces" in the form of agreed methods - witness the
"pass a file-like object" requirements in a lot of APIs. An interface would
just formalise that.
There are proposals for interfaces floating around - I believe the Python
Enhancement Proposal 245 is gaining popularity.
"Python Interface Syntax"
http://python.sourceforge.net/peps/pep-0245.html
Richard
tszeto
"Richard Jones" <ric...@bizarsoftware.com.au> wrote in message
news:mailman.100147214...@python.org...
Markus Schaber
Richard Jones <ric...@bizarsoftware.com.au> schrub:
> On Wednesday 26 September 2001 11:50, Paul Rubin wrote:
>> "tszeto" <tsz...@mindspring.com> writes:
>> > Was wondering if Python supported 'Interfaces' (something akin to
>> > Java interfaces)? Or if there's a workaround to get the same thing.
>>
>> Java interfaces are a workaround for java's non-support of multiple
>> base classes in objects. Python supports multiple base classes, so
>> it doesn't need a workaround for their absence.
>
> Er, no. They may be percieved as that, but since interfaces can't
> actually _do_ anything, whereas multiple inheritance _can_, I believe
> this is a dead herring.
It gets even somehow perverse in java: interfaces can bring code with
them in the never java versions, using inner classes:
public interface container {
public class embedded {
public void test() {
System.out.println("Hello");
}
}
}
> Interfaces are an extremely useful form of "type" checking for OO
> systems. Python already has "interfaces" in the form of agreed methods
> - witness the "pass a file-like object" requirements in a lot of APIs.
> An interface would just formalise that.
That is correct. In a lot of cases, such interfaces are a helpful
instrument to find bugs, because they force such agreements. But the
way they are implemented in Java, those are not as flexible as someone
could wish it in some cases. Python doesn't enforce anything, thus the
programmer has to know what he does - but he also can do whatever he
wants because he knows what he does.
markus
--
"The strength of the Constitution lies entirely in the determination of
each citizen to defend it. Only if every single citizen feels duty
bound to do his share in this defense are the constitutional rights
secure." -- Albert Einstein
Carl Banks
IMHO, ***THE*** best thing about Python is that inheritance and
interfaces and other such tricks are not required to get polymorphic
behavior.
Take, for example, StringIO objects. They are not syntactically
related to File objects in any way: neither is derived from the other,
they are not derived from a common base class, and they do not
implement a common "official" interface. Yet, because StringIO
objects provide the same methods that File objects provide, one can
use StringIO object as if they were an ordinary File objects.
Basically, if something looks like a File object, and acts like a File
object, one can use it like a File object. So, unlike Java, you don't
need interfaces to get polymorphic behavior in Python.
Now, if you want intefaces so as to catch errors when your classes
fail to implement required methods, Python doesn't have anything like
that. But you can define a function that explicitly checks whether
the class has the methods you require:
def assert_provides_interface (klass):
assert has_attr (klass, 'methodX')
assert type(klass.methodX) == MethodType
...
class Y:
def methodX ():
...
assert_provides_interface (Y)
This is a simple example; there's probably thousands of ways to
improve it.
--
CARL BANKS
Titus Brown
>tszeto <tsz...@mindspring.com> wrote:
>> Hello,
>>
>> Was wondering if Python supported 'Interfaces' (something akin to Java
>> interfaces)? Or if there's a workaround to get the same thing.
>
>IMHO, ***THE*** best thing about Python is that inheritance and
>interfaces and other such tricks are not required to get polymorphic
>behavior.
>
>Take, for example, StringIO objects. They are not syntactically
>related to File objects in any way: neither is derived from the other,
>they are not derived from a common base class, and they do not
>implement a common "official" interface. Yet, because StringIO
>objects provide the same methods that File objects provide, one can
>use StringIO object as if they were an ordinary File objects.
>
>Basically, if something looks like a File object, and acts like a File
>object, one can use it like a File object. So, unlike Java, you don't
>need interfaces to get polymorphic behavior in Python.
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...
cheers,
--titus
chris liechti
news:9ot405$3bo$1...@chabry.caltech.edu:
>>object, one can use it like a File object. So, unlike Java, you don't
>>need interfaces to get polymorphic behavior in Python.
>
> 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...
this does not require an "interface". in my opinion a cleaner atempt would
have been if a file-like object had existed (in the standard library).
classes that want to behave like a file could inherit from that class.
(that class would also contain a standard implementation for readline,
readlines, etc. so that a minimal, extending class would only need to
provide read and write methods.
[for OO newbees: such a file like template class is a so called "abstract
class", a class which is partly implemented but some methods are left
unimplemented (or in python do a "raise 'not implemented'" exception)]
(this principle is used in Java's InputStream, OutputStream and others,
which serve as base class for e.g. FileInpuStram)
my point:
some templates in the standard library would help to avoid such problems
like mentioned above. something like "AbstractFile" would be nice.
--
chris <cliechti at gmx.net>
Tim Hammerquist
This sounds like one of the many threads in c.l.smalltalk. :)
If you want to use interface-style type checking, the following might
work for you:
class MyInterface:
# define
class MyIFClass1(MyInterface):
# implement
class MyIFClass2(MyInterface):
# implement
class MyIFException(Exception, MyInterface):
# implement and extend
and use isinstance(obj, MyInterface) to see if it implements it.
It doesn't survive someone deleting keys from the o.__dict__ attribute,
but Python's run-time nature precluded that long ago, didn't it?
--
I'm not an alien. I'm discontent.
-- Stan, "The Faculty"
Lee Morgan
>
>
> Now, if you want intefaces so as to catch errors when your classes
> fail to implement required methods, Python doesn't have anything like
> that. But you can define a function that explicitly checks whether
> the class has the methods you require:
>
> def assert_provides_interface (klass):
> assert has_attr (klass, 'methodX')
> assert type(klass.methodX) == MethodType
> ...
>
> class Y:
> def methodX ():
> ...
>
> assert_provides_interface (Y)
>
>
A previous poster also suggested mutiple inheritance that raises errors when
methods aren't implemented. That implementation mean you get errors only at
runtime when the method is called.
I'd like to see interfaces to make this error checking explicit at byte-compile
time.
As you suggest, due to Python's easy introspective behaviour you can implement
ways to do this yourself, but wouldn't an Interface keyword handle this alot
more cleanly - retaining the philosophy there's only one right way to do it.
I'd like to see an Interface implementation, even if it only really provides
no-brainer errors when refactoring code.
Cheers
--
Lee Morgan
Brian Quinlan
> A previous poster also suggested mutiple inheritance that
> raises errors when methods aren't implemented. That
> implementation mean you get errors only at runtime when
> the method is called.
>
> I'd like to see interfaces to make this error checking
> explicit at byte-compile time.
Aside from the fact that this would not fit at all with the rest of
Python, from a philosophical point of view, it would also require a
complete revamp of the Python compilation semantics to work (imports
would have to be evaluated a compile-time, type-checking would have to
be done at compile-time, etc.).
Paul Prescod (leader of the types SIG) has done some thinking about
interfaces in Python but, in his model, they would be runtime
constructs like everything else.
Actually, the more I think about, the more your idea horrifies me :-)
Cheers,
Brian
Carl Banks
> In article <dqvso9...@10.0.0.1>, Carl Banks <id...@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.
>
> 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
Titus Brown
>> "interfaces sometimes good" ]
>>
>> 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...
>
>This sounds like one of the many threads in c.l.smalltalk. :)
>
>If you want to use interface-style type checking, the following might
>work for you:
>
>class MyInterface:
> # define
>
>class MyIFClass1(MyInterface):
> # implement
>
>class MyIFClass2(MyInterface):
> # implement
>
>class MyIFException(Exception, MyInterface):
> # implement and extend
>
>and use isinstance(obj, MyInterface) to see if it implements it.
Well heeeeck, I can write an inheritance based type checker any hour of
the day, but if the language libraries don't support it, then you're
half pissin' into the wind, aren't you...
>It doesn't survive someone deleting keys from the o.__dict__ attribute,
>but Python's run-time nature precluded that long ago, didn't it?
;)
--titus, who loves programming in Python but wishes that there were even MORE
nice, simple solutions to complex problems.
Titus Brown
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
Lee Morgan
>
> Aside from the fact that this would not fit at all with the rest of
> Python, from a philosophical point of view, it would also require a
> complete revamp of the Python compilation semantics to work (imports
> would have to be evaluated a compile-time, type-checking would have to
> be done at compile-time, etc.).
>
> Paul Prescod (leader of the types SIG) has done some thinking about
> interfaces in Python but, in his model, they would be runtime
> constructs like everything else.
>
> Actually, the more I think about, the more your idea horrifies me :-)
>
Aghast, don't be horrified, its only an idea :-)
Dynamic types, late binding and guaranteed tracebacks are great, but if you're
targeting production code you want to handle errors gracefully and ensure
interfaces are implemented. A pretty traceback is a powerful tool in my hands,
but in my customers...
I don't understand what runtime interfaces get you at all. From my distant
memory of Java a class implements an interface, and therefore guarantees its
existence.
Ah haa - maybe I get it now, do you mean python interface's would supply the
base interface which you could override? And if so wouldn't the type/class
unification provide a cleaner way of doing it? Or would an interface just
guarantee some base class's __init__ is called?
Hmm, I should really read the Interface PEP!
Enlightenment welcome, cheers
--
Lee Morgan
Markus Schaber
Lee Morgan <unk...@lee-morgan.net> schrub:
> I don't understand what runtime interfaces get you at all. From my
> distant memory of Java a class implements an interface, and therefore
> guarantees its existence.
>
> Ah haa - maybe I get it now, do you mean python interface's would
> supply the base interface which you could override? And if so wouldn't
> the type/class unification provide a cleaner way of doing it? Or would
> an interface just guarantee some base class's __init__ is called?
>
> Hmm, I should really read the Interface PEP!
I would agree.
As far as I remember, you ask the object in question to give you a
specific interface, and the object returns an instance that is
guaranteed to implement the interface (could be the object itsself or a
wrapper). When this fails, maybe the interface itsself knows how to
wrap around the object and can create such one.
Laurent Szyster
>
> Richard Jones <ric...@bizarsoftware.com.au> schrub:
>
> > On Wednesday 26 September 2001 11:50, Paul Rubin wrote:
> >
> > Interfaces are an extremely useful form of "type" checking for OO
> > systems. Python already has "interfaces" in the form of agreed
> > methods - witness the "pass a file-like object" requirements in a
> > lot of APIs. An interface would just formalise that.
>
> That is correct. In a lot of cases, such interfaces are a helpful
> instrument to find bugs, because they force such agreements. But the
> way they are implemented in Java, those are not as flexible as
> someone could wish it in some cases. Python doesn't enforce anything,
> thus the programmer has to know what he does - but he also can do
> whatever he wants because he knows what he does.
The last part of your last sentence is a nice quote to promote
Python vs. Java:
"(with Python) the programmer has to know what he does - but he
also can do whatever he wants because he knows what he does"
Laurent
Markus Schaber
Laurent Szyster <laurent...@q-survey.be> schrub:
>> That is correct. In a lot of cases, such interfaces are a helpful
>> instrument to find bugs, because they force such agreements. But the
>> way they are implemented in Java, those are not as flexible as
>> someone could wish it in some cases. Python doesn't enforce anything,
>> thus the programmer has to know what he does - but he also can do
>> whatever he wants because he knows what he does.
>
> The last part of your last sentence is a nice quote to promote
> Python vs. Java:
>
> "(with Python) the programmer has to know what he does - but he
> also can do whatever he wants because he knows what he does"
Well - maybe. But the same applies to C void pointers, and the sentence
"with C void pointers, the programmer has to know what he does - but he
also can do whatever he wants because he knows what he does" doesn't
really sound like promotion for C :-)
Carl Banks
> In article <k50uo9...@10.0.0.1>, Carl Banks <id...@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
Titus Brown
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
Boyd Roberts
> 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.
would someone care telling me why you would even think of using
seek or tell when it comes to RFC 822? err, it's a message format
but i'm inferring that the module slices and dices too.
Carl Banks
>
> 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.
Well, I do agree that is the downside to not having interfaces.
>>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?
Heavens, no. Use the built-in file type as a reference. And have
Guido decree that it is so.
> 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... ;)
Well, the C++ compiler in gcc adds signatures as an extension; I
originally learned about them from gcc's info documentation.
According to that source, other languages that have them are ML
(evidently where they originated), Haskell (called type classes
there), Modula-2 and Modula-3, and some other languages I've never
heard of.
The info node is interesting and explains signatures pretty well. If
you don't have access to gcc's info documentation, you can probably
find a copy online with a Google search on these words (not quoted):
gnu signature polymorphism purdue haskell
--
CARL BANKS
Quinn Dunkan
>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.
My feeling is that there are two python "styles" which address this:
Try and see (i.e. catch the AttributeError, this is what you called "hacked"
above). Also called "better to ask forgiveness".
Provide good documentation. Docstrings are good for this. Of course, many
want to know why you should document in english and make humans read it rather
than documenting in the programming language (via interfaces) and make the
computer read it. My answer is that interfaces add complexity and english
(well, natural language (or even unnatural language, like Dutch)) often works
just fine for this. If your interface requirements are so complicated that
it's hard to express and follow in english (or it's hard to know what to
document), maybe your code needs some work. Of course, there are situations
that refute this answer, which is why people still want interfaces.
Based on the above, rfc822 should have either 1- included "if the file
supports seek() it must support tell() (or was it the other way around?)" in
the documentation, 2- checked for the existence of both seek() and tell()
before it started using them, or 3- not used seek() and tell() at all, if
possible without complexity.
In this instance, I'd favor 2. If you're feeling like doing a good deed, you
could fix rfc822 and submit a patch :)
Someone must have unplugged Alex or deleted his state pickle... both
"interfaces" and "signature-oriented polymorphism" have come up and he's
nowhere to be seen.
Steve Holden
[ ... ]
> Someone must have unplugged Alex or deleted his state pickle... both
> "interfaces" and "signature-oriented polymorphism" have come up and he's
> nowhere to be seen.
In a Nutshell, he's busy!
regards
Steve
--
http://www.holdenweb.com/