typetesting, adaptation, typeclasses, ... (was Re: isinstance() considered harmful)

[Alex Martelli]

Jason Orendorff wrote:
        ...
>> Having to arbitrarily pick one of .append and .extend as
>> "more primitive" in the definition of a list typeclass is
>> quite inelegant, for example.
> 
> You're treading dangerously close to preferring a mathematician's
> sense of elegance to a programmer's sense of clarity.

That's a risk one runs when in mental "Haskell mode", yes, because
Haskell's elegance is so stunning.

> I'd guess that for the ordinary programmer, append() feels
> more primitive (perhaps because it deals with atoms and not
> molecules; and perhaps because it's used more often).

Refusing to guess in presence of ambiguity is one of Python's
tenets, though.


> Actually I guess I would define extend() in terms of
> __setitem__(self, slice), and append() in terms of insert().

You could define them all in terms of slice setting, yes.

I think in this sense slice setting is 'the' most primitive
mutator of Python mutable sequences -- you can most
easily define all others in its terms but not vice versa.


> Anyway, in Java the idiom is to provide an interface and
> then provide an abstract base class that implements most
> of the interface (recursively, if you like; I think some
> java.io class does this).  This means you can't add methods
> to the interface later, but it's still IMHO more useful
> than what Python has (no explicit interfaces at all).

Since those abstract base classes, in Java, cannot be
mixin-inherited from, I disagree that they're more useful
than what Python has.  If you like implements/extends
as the only way to build objects acceptable to a given
library, then (while not mathematically elegant) Python's
lack of distinction between classes and interfaces (like
C++'s) is pragmatically sufficient -- and overall more
useful thanks to multiple inheritance.


Alex