Date manipulation and Java 'interface' equivalents

Martin Christensen knightsofspamalot-factotum at
Tue Nov 7 21:41:51 CET 2000

First of all, sorry for my late reply, and thanks to all the people
who have provided useful information. I will look at the two proposed
date handling classes at the Starship.

>>>>> "Alex" == Alex Martelli <aleaxit at> writes:
Alex> Python does not currently formalize the idea of "interface",
Alex> just as Java does not formalize its crucial part (the
Alex> "programming by contract" expression of pre-, post-, and
Alex> invariant-conditions of the interface's various methods).  But,
Alex> in each case, the concept is easily realized and plays an
Alex> important role.

No, I wasn't so much interested in programming by contract, though I
appreciate its value. I am a big fan of assertions, and I miss an
optional invariant.

Alex> For example, consider the idea of "a sequence of items that can
Alex> be iterated on, one after the other".


class foo implements iterator {

or something like that. I don't recall the exact interface, but it's
pretty easy. I've used that before.


Alex> The point is that your object is a sequence if, and only if, it
Alex> implements a method of this description; it makes no difference
Alex> whether it does so directly, or by inheriting by whatever other
Alex> class you choose.  This can be called "signature-based
Alex> polymorphism".  Like all typing issues in Python, it's only
Alex> checked dynamically (just as, in Java, are such things as
Alex> whether the Object references you're returning can correctly be
Alex> cast to whatever it is that you need; only dynamic checks are
Alex> done) -- in exchange for which, you get extreme flexibility and
Alex> fluidity compared to a mostly-statically-typed language.

I'm not sure I get your point, and I'd much appreciate elaboration. I
have to manipulate different goods, say, knobs, dials and
blinkenlights, and each of these are represented by objects of
different classes, naturally. However, for some operations I want to
manipulate these objects without necessarily knowing what kind of
objects they are. In Java I would accomplish this by having them
implement an interfacy Thingy that enables me to throw them around as
I wish, and when I need the specific qualities of a certain class I
can cast the Thingy object to whatever's relevant.

Alex> The formalization of the 'interface' concept in Java does not
Alex> really buy you all that much in practice compared with Python's
Alex> pragmatically-equivalent (more dynamic and fluid) approach.

I wouldn't know, since I'm a newcomer to Python and dynamic typing in


Alex> Despite my background being in statically typed languages, I'm
Alex> coming to be convinced that the tradeoff is an overall win for
Alex> dynamic typing in most real situations...

I'm beginning to see that, but only beginning.

Thanks for a very enlightening post, but we newbies tend to be
thickheaded, I'm afraid. :-)


GPG public key:

More information about the Python-list mailing list