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

[Kragen Sitaker]

"Jason Orendorff" <jason at jorendorff.com> writes:
> Alex Martelli wrote:
> > Actually, it's more frequent that two (occasionally more)
> > operations need to be in a certain connection with each other,
> > but none of them is 'intrinsically' primitive wrt the others.
> > 
> > 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.
> 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).
> 
> Actually I guess I would define extend() in terms of
> __setitem__(self, slice), and append() in terms of insert().
> 
> I wouldn't bother defining __setitem__() in terms of
> insert() and __delitem__().  It just seems a bit much to me.

MetaPy.Sugar.Sequence is a typeclass for Python sequences; it's in
MetaPy, which is at http://pobox.com/~kragen/sw/MetaPy-7.tar.gz or
.zip.

In MetaPy.Sugar.Sequence, I define everything in terms of
simple_getitem, simple_setitem, simple_delitem, insert, and __len__.
Sequences whose lengths aren't mutable don't define simple_delitem and
insert (but then they must define __add__, __radd__, and __mul__
themselves.)  The simple_* operations don't need to handle slices.

append is defined in terms of extend, which is defined in terms of
__setitem__ with a slice, which is defined in terms of simple_setitem
and (when the length changes) simple_delitem and insert.

The idea behind this long chain is that redefining any operation (for
example, extend or __setitem__ with a slice) in a more efficient way
should make the maximal set of operations more efficient.

There's a fair bit of typetesting is there to distinguish slice
indices from integer indices; is there a better way of doing it?

I'm pondering what to rename things; I'm thinking:
MetaPy -> multipy "Multi-paradigm Python"
MetaPy.Sugar -> multipy.typeclass
MetaPy.Sugar.Sequence -> multipy.sugar.seq
MetaPy.Sugar.Mapping -> multipy.sugar.mapping

Any thoughts?