[Python-3000] Fw: typeclasses, duck-typing

[Phillip J. Eby]

At 02:50 PM 5/12/2006 +1200, Greg Ewing wrote:
>These are large assumptions, which I suspect are at
>least 87.43% wrong. Don't make the mistake of thinking
>that everyone has the same preferences as you.

And that's about 51.7% patronizing; don't make the mistake of thinking that 
my assumption was based on my own preferences.  ;-)


>If that were all it said, I'd think "!#$#??? Why are they messing
>around with something that's not broken?" (i.e. naming of special
>methods).

I didn't say it's broken; that doesn't mean it couldn't be improved upon.

Nonetheless, I agree that if it were purely a syntactic change, it wouldn't 
be worth changing.


>If it went on to talk about generic functions, I'd be very
>uncomfortable, because I still have deep reservations about
>that whole idea.

It would be helpful if you could get those reservations out into the open, 
where they could become part of the process.

Guido has also expressed reservations, so I wouldn't worry about it too 
much.  My semi-proposal here is really a "wild fringe" idea in the overall 
scheme of things.  Think of it as an attempt to see what would happen if 
overloaded functions were fundamental to the language, such that:

1. all the built-in overloaded functions (iter(), len(), etc.) weren't 
special cases, but just implementations of something that any programmer 
can add to the language

2. there was a uniform way to add new implementations to an overloadable 
function

3. the overloading mechanism was itself overloadable, so that it could be 
extended for applications or frameworks with more specialized dispatch needs

4. type annotations on arguments can be used to specify what types an 
implementation applies to

My take on it so far is that if you do these things, you can get rid of a 
bunch of magic things -- possibly including the peculiarities of the 
current double-dispatch system for binary operators (including both 
arithmetic and comparison).

But my take doesn't really count; Guido's description of overloading as 
being a 20% niche certainly doesn't mesh with this approach.  But I don't 
know if his reasoning has more to do with an assumption that overloaded 
dispatching is necessarily complex.  There's nothing that stops a 
*particular* kind of overloading from being implemented by setting tp_* 
slots or __magic__ names under the hood.  I just think that we could make 
that an implementation detail, rather than the interface, just like we 
don't normally do this to create classes:

      someclass = type('someclass',(base1,base2),classdict)

nor do we normally get object attributes using 'getattr()' when 'foo.bar' 
will do.  So I think making overloading a uniform concept in terms of 
having syntax for it that uniformly applies to user-defined and built-in 
generic operations will simplify things nicely.

Now, if Guido decides that he *agrees* with me, *then* you should 
worry.  ;)  Until then, I would interpret his position as being against 
such a "radical" conceptual change, despite the fact that it would change 
the implementation hardly at all.  (I've spent some time sketching a Python 
implementation, and I think I can actually make it work uniformly in Python 
2.4 even for the existing built-ins like iter(), with a few kludges.  But I 
probably won't get it finished tonight.)