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

[Phillip J. Eby]

At 11:39 AM 5/12/2006 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
>>I'm only showing this example because I think getting rid of 
>>__magic_names__ for operations could be a good thing for readability, and 
>>it would remove an element of "magic" from today's Python.
>
>Although overloadable functions are themselves somewhat
>magical, so this could be seen as just replacing one
>kind of magic by another.

Do you consider overloading in Java or C++ to be magical?  Okay, maybe a 
little in C++.  ;)


>>That *would* be a paradigm shift, albeit one that I doubt many Python 
>>users would seriously object to.
>
>On the contrary, I expect many Python users would
>object to it very strenuously, unless they somehow
>became convinced that the new paradigm was clearly
>superior overall to the old one. I for one am very
>much unconvinced of that.

I meant only the shift from typing "def __iter__(" to "defop iter(", 
irrespective of how it's implemented.  My assumption is that a majority of 
Python users would either not care which "magical" spelling was used, would 
like getting rid of the '__', or even rejoice at the fact that this allows 
them to create their own "magical" protocols without making up random new 
'__' names of their own.

In other words, I mean that if most people saw something like this in 
"What's new in Python 3.0", I don't think they would freak out:

"""Removal of __magic__ attributes

Special attribute names like '__iter__' have been replaced with use of the 
'defop' keyword, for example, 'defop iter(self)'.  Instead of defining a 
method named 'iter', 'defop iter' defines what the 'iter()' builtin will do 
when passed an object of the corresponding type.  This feature makes it 
easy to create new generic operations like iter() and len() without having 
to define special attribute names and avoid collisions.  See the table 
below for a complete list of translations..."""

Instead, I'd expect most people to view this as either neutral and of no 
consequence, or as a positive improvement in readability and reduction of 
magic.

(In other words, there would be One Obvious Way to Do It when you are 
defining operations that aren't limited to a particular class family, and 
the builtin-plus-magic-name convention would no longer be a special case 
for language-defined generic operations.)

I'm not saying my proposals in this regard are perfect.  I think there are 
a lot of places where corner cases need fleshing out, especially with 
regard to n-argument generics (like operator.add and other arithmetic 
operators) and this is all dependent upon having a sensible __signature__ 
system in place.

IOW, it's not a panacea, but I'm pretty positive it's implementable in a 
way that could be done even in Python 2.x using a __future__ statement for 
the 'defop' syntax, assuming we get type annotations of some kind in some 
2.x version.  I'm going to throw together a Python-only prototype to verify 
this, though.

(It would even be backward compatible as far as the Python/C API, btw -- in 
2.x 'defop' for builtins can be implemented by just setting the magic 
attributes, and I will prototype that in my pure-Python proof-of-concept.)