Missing interfaces in Python...

[Peter Maas]

Python is a very dynamic language. Java is a very static language.

What is the difference between "static" and "very static"? Is Java
more static than Fortran I?

Peter Maas, Aachen

 

[olsongt]

(e-mail address removed):

The problem with that of course, is that there's much more to being a duck
than being called 'duck'.

public interface JarFile {
void explode();
}
public interface NuclearBomb {
void explode();
}
http://www.beust.com/weblog/archives/000269.html

Not that I disagree with you, but interfaces don't really guarantee any
semantics either. You'd probably need to use Eiffel if you really want
to design by contract.

public class EarFile implements JarFile {
void explode()
{
HackerTools.WipeHardDrive();
}

}

 

[Roy Smith]

He probably means that with interfaces one could test compliance
with the interface as a whole instead of testing each member and
each signature as a single piece.

All interfaces (as implemented by Java) prove is that your class has a
bunch of methods with the right names and signatures. It doesn't
prove that those methods do the right things. It's like having a
bouncer in front of a nightclub stopping people saying, "You can't
come in here unless you tell me you're over 21 and aren't wearing
scruffy jeans". OK, I'm happy to tell you that, but if you don't
check to make sure it's true, you're going to have a lot of scruffy 18
year olds crashing your party.

 

[Jonathan Daugherty]

# All interfaces (as implemented by Java) prove is that your class has
# a bunch of methods with the right names and signatures. It doesn't
# prove that those methods do the right things.

I don't think anyone is suggesting that interfaces do (or should)
prove that the implemented methods actually do the right thing.

 

[Dennis Lee Bieber]

What is the difference between "static" and "very static"? Is Java
more static than Fortran I?

Given that FORTRAN will happily upconvert numeric types as needed in
equations (and downconvert on the final assignment too, as I recall)...
int = double * (int + float)

 

[Alex Martelli]

All interfaces (as implemented by Java) prove is that your class has a
bunch of methods with the right names and signatures. It doesn't
prove that those methods do the right things. It's like having a

There's a _tiny_ bit more -- accidental clashes of methodnames are more
likely to be avoided. I.e.,

interface ILottery {
void draw();
};

interface IGunslinger {
void draw();
};

interface IPainter {
void draw();
};

A class asserting, e.g., "implements IPainter", doesn't thereby risk
being accidentally misused where an IGunslinger is required (OTOH,
implementing >1 of these IS a bother, but that's sort of inevitable).


Alex

 

[Kay Schluehr]

I'm coming from a Java background, so please don't stone me...

I see that Python is missing "interfaces". The concept of an interface
is a key to good programming design in Java, but I've read that they
aren't really necessary in Python. I am wondering what technique I can
use in Python to get the same benefits to a program design that I would
get with interfaces in Java.

For example, if I want to have a program with a Car object, and a Bus
object. I want both of these objects to present a common group of
methods that can be used by Mechanic objects, but slightly different
methods that can be used by Driver objects.

In Java I would accomplish this by defining an IFixable interface that
would be implemented by both the Car and Bus objects. Mechanic objects
would work with any object implementing this interface.

How would I approach this problem in Python? I think I would use an
abstract class instead of an interface for IFixable, since Python
supports multiple inheritance, but I'm not sure this is correct.

Thanks for any suggestions.

Scott Huey

The answer is called "duck typing" or "structural typing". Any two
classes that implement a set of methods with pairwise equal signatures
can be considered as "presenting a group of methods". You do not have
to create a special construct and assign it to classes ( e.g. via an
"implements" directive ) in order to make it work. That's because you
are not enforced to know the type of an object at compile time. Car and
Bus classes may be selected from two completely different libraries
without any common convention but it is still possible ( though not
very likely without any adaption ) that they work together and show
sound behaviour ( you have to prove at least certain behavioural
properties using unit tests ).

"Duck typing" is also the reason why coupling of an interface with an
implementation is not harmfull in Python. You won't find many deep
class hierarchies and extensive frameworks. This has the advantage that
a classification you have done once at the beginning of your project in
the design phase is not considered to be carved in stone.
In Java/C#/C++ you can achieve many of the same effects of using
"generic" or "templates" but if you are not start coding with them from
the very beginning you loose many of their benfits. In Python this is a
non-issue.

 

[Rene Pijlman]

Kay Schluehr:

You won't find many deep class hierarchies and extensive frameworks.

Zope comes to mind.

This has the advantage that a classification you have done once at
the beginning of your project in the design phase is not considered
to be carved in stone.

Zope 3 comes to mind.

 

[bruno at modulix]

Everyone is getting off track here.

Not that much...

Java has interfaces because it doesn't support multiple inheritance.

Java as interfaces because it relies on type declaration for subtyping
*and* doesn't support MI.

Python supports MI, so you don't need to use the seperate concept of an
interface.

s/supports MI/doesn't rely on type declaration for subtyping/

Would we need interfaces in Python if Python did not support MI ? Of
course not, duck typing would still work.

(snip)

The general wisdom is that Abstract Base Classes aren't pythonic
though.

*Pure* abstract base classes (ie: abc without any implementation) are
not Pythonic. I often use abc's that provides the 'guts' for common
stuff, but are meant to be specialized for use (this is pretty common in
frameworks).

(snip the rest - mostly agree)

 

[bruno at modulix]

Kay Schluehr:



Zope comes to mind.




Zope 3 comes to mind.

Yeps. Now Zope is a world in itself, and is not really pythonic IMHO.

 

[Ben]

Yeps. Now Zope is a world in itself, and is not really pythonic IMHO.

It seems to me that a lot of python projects reimplement interfaces or
adaption of some kind once they reach a certain size (Zope, PEAK, eggs,
TurboGears, etc), which implies that they really do have some benefits,
particularly in documentation.

Cheers,
Ben

 

[Roy Smith]

There's a _tiny_ bit more -- accidental clashes of methodnames are more
likely to be avoided. I.e.,

interface ILottery {
void draw();
};

interface IGunslinger {
void draw();
};

interface IPainter {
void draw();
};

A class asserting, e.g., "implements IPainter", doesn't thereby risk
being accidentally misused where an IGunslinger is required (OTOH,
implementing >1 of these IS a bother, but that's sort of inevitable).

I suppose, but all you've really done is move the problem to a different
namespace. Which IPainter did you have in mind? The one that has to do
with people who apply oils to canvas, or the one that has to do with ropes
that are used to tie up rowboats?

 

[Neal Becker]

I'm coming from a Java background, so please don't stone me...

I see that Python is missing "interfaces". The concept of an interface
is a key to good programming design in Java, but I've read that they
aren't really necessary in Python. I am wondering what technique I can
use in Python to get the same benefits to a program design that I would
get with interfaces in Java.

For example, if I want to have a program with a Car object, and a Bus
object. I want both of these objects to present a common group of
methods that can be used by Mechanic objects, but slightly different
methods that can be used by Driver objects.

In Java I would accomplish this by defining an IFixable interface that
would be implemented by both the Car and Bus objects. Mechanic objects
would work with any object implementing this interface.

How would I approach this problem in Python? I think I would use an
abstract class instead of an interface for IFixable, since Python
supports multiple inheritance, but I'm not sure this is correct.

Thanks for any suggestions.

I see various answers that Python doesn't need interfaces. OTOH, there are
responses that some large Python apps have implemented them (e.g., zope).
Does anyone have an explanation of why these large systems felt they needed
to implement interfaces?

 

[Alex Martelli]

I suppose, but all you've really done is move the problem to a different
namespace. Which IPainter did you have in mind? The one that has to do
with people who apply oils to canvas, or the one that has to do with ropes
that are used to tie up rowboats?

In Java's excellent naming convention for modules, there's no ambiguity:
I specifically requested it.aleax.artists.IPainter, or else specifically
requested com.panix.roy.boating.IPainter -- nothing stops any language
with a structured namespace for modules from using that convention.


Alex

 

[Roy Smith]

In Java's excellent naming convention for modules, there's no ambiguity:
I specifically requested it.aleax.artists.IPainter, or else specifically
requested com.panix.roy.boating.IPainter -- nothing stops any language
with a structured namespace for modules from using that convention.

This is true. This is one of the things Java does well.

 

[Alex Martelli]

It seems to me that a lot of python projects reimplement interfaces or
adaption of some kind once they reach a certain size (Zope, PEAK, eggs,
TurboGears, etc), which implies that they really do have some benefits,
particularly in documentation.

PEAK is an interesting counterexample, particularly since Philip Eby
tends to be "ahead of the curve": it appears that he's determined that
``generic functions'' (with ``multimethods'') are a superior approach,
and seems to have convinced Guido to the point that GFs are the
alternative being actively explored for Py3k. I will admit that, while
still undecided, I'm halfway-convinced enough not to mourn for PEP 246.

((It's possible to implement protocols, a la PyProtocols and as
advocated in PEP 246, in terms of GFs, or viceversa; in PEAK, it's
GFs-in-terms-of-protocols for strictly historical reasons, but the
advantage along various axes seems to be to the
protocols-in-terms-of-GFs camp; since protocols are a strict superset of
interfaces...))

BTW, this _could_ be seen as yet another case of "reimplementing LISP",
since Lisp/CLOS was always based on GFs/multimethods...;-).


Alex

 

[Rene Pijlman]

Alex Martelli:

PEAK is an interesting counterexample, particularly since Philip Eby
tends to be "ahead of the curve":

I never noticed PEAK before. Is it well worth studying?

 

[Rene Pijlman]

Neal Becker:

I see various answers that Python doesn't need interfaces. OTOH, there are
responses that some large Python apps have implemented them (e.g., zope).
Does anyone have an explanation of why these large systems felt they needed
to implement interfaces?

A programming language doesn't need interfaces, unless it insists on
compile time checking of just about everything.

The idea of interfaces arises from the construction and maintenance of
large and complex software systems. It provides a level of abstraction
that makes it easier to talk about a component and document what it
requires from and offers to it's environment.

Also, interfaces can make this documentation first-class objects, so test
tools, IDE's and software design tools can take advantage of it.

 

[bruno at modulix]

Neal Becker wrote:
(snip)

I see various answers that Python doesn't need interfaces. OTOH, there are
responses that some large Python apps have implemented them (e.g., zope).
Does anyone have an explanation of why these large systems felt they needed
to implement interfaces?

These "interface" ("protocol" would be a better name IMHO) systems are
not exactly the same as Java's interfaces. They are mainly used a a way
to describe components and allow for component adaptation and
substitutability. Think of it as a highly decoupled pluggable component
system, not as a language-level subtyping mechanism. BTW, you'll notice
that these projects (Zope, Twisted, PEAK, ...) are mostly large frameworks.

My 2 cents...

 

[Alex Martelli]

Alex Martelli:

I never noticed PEAK before. Is it well worth studying?

Oh yes.


Alex