[Python-3000] Sane transitive adaptation

[Talin]

Guido van Rossum <guido <at> python.org> writes:

> Before we worry about the implementation overhead, we need to make
> sure that the resulting paradigm shift isn't going to destroy Python
> as we know it. We already have well-established and well-understood
> machinery for method lookup in a class hierarchy. Are we sure that
> replacing all that with overloadable/extensible functions is really a
> good idea? While classes are technically mutable, in practice few
> classes are modified at run-time. The overloadable functions approach
> seems to encourage tinkering with globally defined (and used)
> functions. For example, what if one library overloads bool(str) so
> that bool("False") == False, while another library assumes the
> traditional meaning (non-zero string => True)?

You know, on the one hand, I've been reading this thread, and I'm
excited about the possibility of generic functions (dynamic dispatch,
duckaplex-typing, whatever you want to call it), but at the same time
I kind of wonder about the eventual effect on the language.

For example, it seems to me that most of the various magic methods,
such as __cmp__, __add__, etc. would be better done with generics,
especially since it gives you much finer control over the type of
the other argument. So instead of having to write:

class X:
   def __cmp__( self, other ):
      if isinstance( other, X ):
         return cmp( self.something, other.something )
      return NotImplemented   # or raise TypeError or whatever

Instead you can just write:

@generic( X, X )
cmp( a, b ):
   return cmp( a.something, b.something )

Similarly, if you add an integer to a string, the overloading machinery
will report the error, instead of having to check it manually in the __add__
method.

The addition of a funamentally new method of control flow - especially
one that is a superset of an existing control flow method - is
something that could potentially ripple through all of the standard
libraries, transforming them beyond recognition. Given the obvious
advantages, it would be hard to justify sticking with the older methods
of doing things.

While that's cool and I would look forward to working with them, I
recognize that there are some downsides.

For one thing, if generic functions are used in a way that truly leverages
their potential, the structure of the code is going to be so different from
2.x that there won't be any possibility of automated migration - unless
you decide up front that the use of generics is going to be restrained and
controlled, at least initially.

Personally I'm fine with breaking from the past. But I wanted to point
out what some of the potential consequences would be.

-- Talin