I'm going to stick to the term "(dynamically, or run-time) overloaded functions" for now, despite criticism of this term; the alternatives "generic functions", "multi-methods" and "dispatch" have been (rightly) criticized as well.

A slightly optimized implementation is here: http://svn.python.org/view/sandbox/trunk/overload/

Phillip Eby has suggested that my implementation is too slow; but I recommend that you run test_overloading.py and see for yourself. (This requires the Python 2.5a1 release that was just released from python.org.)

Phillip also suggested that I use issubclass() instead of relying on the MRO (method resolution order); he believes the MRO approach can cause false precision. I'm not sure I believe that, since for single dispatch my approach actually matches the class method lookup approach exactly.

There are tons of additional features or potential requirements. For example, should there be a mechanism to invoke the "next" applicable method? But the algorithm doesn't clearly produce a next method. Also, in the case of ambiguity, should an exception be raised or the default method be invoked? (Or perhaps the "next" method, if we can agree on what it is?)

In terms of optimization, I believe that a little bit of code generation could make overloaded functions nearly as fast as hand-coded functions; see 'accelerated' in test_overloading.py.

And no, this isn't for Python 2.5; it's a highly contagious but also highly controversial thing that should be tried out in Python 3000 (or perhaps as a 3rd party add-on for 2.5) first.

I totally forgot that I blogged about this earlier, over a year ago. My implementation then was pathetic compared to today's! Phillip's ideas have helped a lot.

My hope is to eventually drive PyProtocols out of the market. Phillip should be so proud of me. :-)

# the default resolution of tests.
tests()

# loop over the tests, with some extra logic in there.
for x in tests:
    if x:
        some_other_statement()
        if some_other_expression:
            break
        x()
        break

# testing one part.
if tests[3]:
    tests[3]()

# testing one part passing in variables for the expression.
#   always using .expression() and .statement() calls.
if tests[3].expression(a=3, b=4):
    tests[3].statement(44)


# remove one test.
del tests[1]

# add another test later.
tests += elif expression:
    statement

tests = if(x == 4):
  print "1 blabla :%s:" % x
tests += elif x == 55:
  print "2 asdf :%s:" % x
tests += else:
  print "3 qwer :%s:" % x

tests(x=44)

from overloading import overloaded

@overloaded
def foo(x):
    print x

@foo.register(int)
def foo(x):
    print hex(x)

print foo("abc")

Traceback (most recent call last):
  File "x.py", line 11, in <module>
    print foo("abc")
  File "x.py", line 9, in foo
    print hex(x)
TypeError: hex() argument can't be converted to hex

def register(self, signature):
    def helper(f):
        self.registry[signature] = f
        if f.__name__ = self.__name__:
            return self
        return name

def register(self, signature):
    def helper(f):
        self.registry[signature] = f
        if f.__name__ = self.__name__:
            return self
        return name
    return helper

def register(self, signature):
    def helper(f):
        self._do_registration(signature, f) # Store in mapping, or maybe some other mechanism
        if f.__name__ == self.__name__:
            return self
        return f
    return helper

@overloaded
def foo(x):
    "prints x"
    print x

@foo.register(int)
def foo(x):
    "prints the hex representation of x
    print hex(x)

>>> help(foo)
Help on function foo in module __main__:

foo(x)
    print x

    <int>:
        prints the hex representation of x

    <float>:
        prints some other special representaion.

     ...