[Python-Dev] type categories (redux?)

[Samuele Pedroni]

[Andrew Koenig]
>Michael> I may be getting lost in subthreads here, but are we still
>Michael> talking about multimethods?
>
>Well, I started by talking about type categories and ways of
>writing programs that tested them.  Dave Abrahams said, in effect,
>that I was really just talking about multimethods.  I'm still
>not convinced.

On one hand we have

[0. destructuring pattern matching which
is a kind of local control-flow construct]
1. Multiple dispatch [and predicate dispatch]
which are about generic functions defined
as a set of tuples (function,signature),
and where, given a tuple of arguments,
one find the applicable function subset based on the signatures
and then tries to induce a total/partial order
on the subset based on the arguments and calls the inferior.
The signatures typically involve types(classes)
and the order is about subtype(subclass) relationshisps.
[again see
http://www.cs.washington.edu/research/projects/cecil/www/pubs/dispatching.html
 ]


On the other hand:

Dave Abrahams wants multiple dispatch and
 also wants to dispatch e.g. on arg being a mapping.

Now to define  in Python what a mapping is
as first-class object/formal language construct
is a kind of Holy Grail.

So the discussion
i) type categories as (Zope) interfaces
ii) type categories in terms of hasattr
[not totally safe but used in practice]
iii) type categories in terms of predicates
etc

It is maybe worth to underline that
[this was somehow implicit in much of the discussion]:
no amount of formalism  and what-not can make an approach extending Python
as-is safer than (ii) unless with the addition of some
kind of explicitness (explicit tagging or labeling, explicit
predicate (forced) assertion, explicit interfaces with
central register or not).


IMHO Dave can wait for a long long time <wink>
or go the pragmatical route:

*) either integrating (Zope) interfaces in the dispatch
  model
*) or adopting some minimal form of predicate dispatching too,
noticing that once you have multi-method dispatch
you can define e.g.

defgeneric ismapping

addmethod ismapping(obj: Any): return False
addmethod ismapping(obj: dict): return True

[in CLIM e.g. the notion of procols is defined
in this way too (or through abstract superclasses)]

and you gain some flexibility because a user
 - composing a system -
can redefine this for a part of the type
hierarchy in terms of hasattr or what-not ...
or define ismapping for a pre-existent type
a posteriori.

It's a bit more flexible than the registry
 approach in Zope interfaces (if I understand
that correctly).
But you don't have a direct notion of
 subcategory (this can be a problem or not)

*) or a mixture of the two approaches
[about which I admit I should think more]

[I start to feel that Python obession
about not being explicit about protocols
has gone a bit too far ( it's just a very personal feel),
even in Smalltalk people add to Object things like

Object>>>respondsToArithmetic
    ^false.
Object>>>isSequenceable
    ^false.
...
and then redefine them to return true somewhere down
the hierarchy, and use these predicates to select
behavior.

It is used sparingly, but it is used.

"We" could'nt do that because
in Python there was no modifiable ur-object,
but both with a registry or multi-methods one
can enable essentially this.]

for-better-or-worse-Alex-Martelli-wasn't-listening-
and-we-haven't-even-scratched-the-interactions-or-non-interactions-
with-PEP-246'ly y'rs.

-*-
"In my experience, much of language design is like this. We think we know how
it will all come out, but we don't always. Usage patterns are often surprising,
as one learns if one is around long enough to design a language or two and then
watch how expectations play out in reality over a course of years. So it's a
gamble. But the only way not to gamble is not to move ahead."
  -- Kent M. Pitman