[Python-3000] my take on "typeclasses"

[Guido van Rossum]

[Michael Chermside]
> > I think the idea of creating a new language with some of the wonderful
> > syntax of Python along with the wonderful type system of Haskell sounds
> > GREAT! I would be very interested, and would like to join in the
> > discussion.
> >
> > But I don't think it belongs in the Python-3000 discussion group. Can
> > this discussion be moved elsewhere? Python 3.0 is going to have types,
> > and they're going to look very similar to the types in Python 2.X --
> > a brand new language would be a separate project.

[Talin]
> Ordinarily I would agree with you on this point, and in fact I
> wouldn't even bring it up at all, except for two data points:
>
> 1) The proposal to include generic function dispatch
>    in Python 3000, based on explicit typing.
>
> 2) The proposal to remove all forms of type testing
>    other than those based on isinstance() (in other words,
>    removing callable, isSequence, isMapping, etc.)
>    (I'm not including attribute testing here because its
>    neither standardized nor systematic.)

Note that these are *proposals*. IMO they are minority proposals and
I'm doubtful that they will fly as you state them here. (For example,
see my other post where I mention that generic/overloading functions
will at best be used to augment traditional class-based dispatch; they
will play a minor role at best.)

My proposal of removing callable() wasn't intended to increase the
number of isinstance() calls. Rather, it was intended to face paranoia
head-on, by saying "just call it!" And (re.sub notwithstanding) APIs
that depend on being able to distinguish between a callable and a
non-callable are usually poor API design, and should be replaced by
other approaches (like keyword arguments).

> The net effect of these proposals is to greatly strengthen
> the capabilities of explicit typing, while seriously crippling
> the use of duck typing. By putting a much greater emphasis on
> explicit typing, we're effectively moving Python away from the
> implcit "duck-typing" that we've known up to this point.
>
> So essentially Python is *already* becoming a different
> language, whether we like it or not.

You're way ahead of me here. You talk like this is a done deal. It
isn't. And in fact I am strongly *against* any kind of "accidental
paradigm shift" like this -- I'm doing my best to prevent those from
happening. (There are some *intentional* paradigm shifts planned, but
they are more about the behavior of some specific built-in types and
operations such as files, strings and mappings, than about the very
foundation of the type system.)

> I think that I agree with the gist of Tomer's point.

Well, to most of us it's far from clear what he's trying to say...

> I'm not
> going to claim that types are useless, but I think we should
> think about ways of dispatching other than types.

Maybe. Although generic/overloaded functions can easily use types
exclusively for dispatch, despite being quite a different paradigm.
(See my sample implementation in sandbox/overload/.)

> What would seem very 'Pythonic' to me would be a system
> whereby objects can not only be dispatched on their
> types but also their *capabilities*. Thus, instead
> of asking the question "Is this a sequence?", we ask
> "Can this be iterated?"

Aside: let's not use the term "capability" for this -- it is a highly
meaningful concept already in the context of security realms.

> In such a model a "sequence type" would simply be a
> set of capabilities that often occur together.

Of course there's nothing to stop us from establishing a convention
that allows one to use a single hasattr() call to test for such a
thing -- or any number of other approaches whose surface API is a
single call: isinstance(), hasattr(), implements(), all are at some
level equivalent. So there's not that much new.

> I think at the very least, we need a way a better
> definition of a "capability", and a formalized way
> to test for its presence. Whether or not that is
> directly wired into the dispatch mechanism (which would
> be cool) is another issue. Certainly attribute testing
> is part of it, but there needs to be agreement on which
> attributes to test.

I think I would encourage proposals here to come up with a lightweight
and reliable convention. It's okay to require that all sequences types
must do something specific before they will be considered to be
sequence by the new testing method -- because if we want to be able to
reliably distinguish between sequences and mappings, we're *somehow*
going to have to cut the tie. The convention should address existing
de-facto categories such as iterable, sequence, file-like, etc., and
also let users (and especially frameworks and libraries) define their
own catagories.

Bill Janssen is proposing that the specific thing a type must do is
inherit from some abstract base class.

Phillip Eby is countering that that isn't sufficient because he wants
to be able to make up his own categories and apply these to existing
types defined by 3rd party libraries.

It would be great if we had a solution that allowed either approach!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)