Connecting Tech Pros Worldwide Forums | Help | Site Map

multimethod (or rather overloading) in Python

anton muhin
Guest
 
Posts: n/a
#1: Jul 18 '05
Dear pythonistas!

I'd like to emulate overloading in Python (like C++).

Let's consider an example:

class A(object): pass
class B(object): pass

Of course, there are some standard overloading implementations for
Python. For example:

def overload(cls):
def wrapper(f):
gl = f.func_globals

next = gl.get(f.func_name, failedOverload_(f.func_name))
def _(obj, *args, **kwargs):
if isinstance(obj, cls):
return f(obj, *args, **kwargs)
else:
return next(obj, *args, **kwargs)
return _

@overload(A)
def foo(_): print 'foo@A'


@overload(B)
def foo(_): print 'foo@B'

However, it obviously doesn't work for classes: I cannot overload
instance methods with such a decorator.

The best way I found is closures. Unfortunatley, in this case I need a hack:

gl = f.func_globals

turns into:

gl = sys._getframe(1).f_locals

and with this hack one can make the following trick:

def poorManOverloadedMethods(someInfo):
@overload(A)
def _(_): print '%s: poorManOverloadedMethods@A' % someInfo

@overload(B)
def _(_): print '%s: poorManOverloadedMethods@B' % someInfo

return _

PMOM = poorManOverloadedMethods('test')

....

Of course, I can imagine some metaclasses magic that would allow to code:

class MyClass(WithOverloading):
@overloadMethod(A)
def someMetod(self, _): ...

But it would rather convoluted: the best idea I have so far is to mangle
methods name in the manner most of C++ compilers do.

Is there better way? Can I unify both @overload and @overloadMethod?

with the best regards,
anton.

anton muhin
Guest
 
Posts: n/a
#2: Jul 18 '05

re: multimethod (or rather overloading) in Python


anton muhin wrote:

Correction:
[color=blue]
> Of course, I can imagine some metaclasses magic that would allow to code:
>
> class MyClass(WithOverloading):
> @overloadMethod(A)
> def someMetod(self, _): ...
>
> But it would rather convoluted: the best idea I have so far is to mangle
> methods name in the manner most of C++ compilers do.[/color]

Stupid me. Of course, name magling is impossible and unnecessary. Sorry.

Still the question remains.

with the best regards,
anton.


Nick Coghlan
Guest
 
Posts: n/a
#3: Jul 18 '05

re: multimethod (or rather overloading) in Python


anton muhin wrote:[color=blue]
> anton muhin wrote:
>
> Correction:
>[color=green]
>> Of course, I can imagine some metaclasses magic that would allow to code:
>>
>> class MyClass(WithOverloading):
>> @overloadMethod(A)
>> def someMetod(self, _): ...
>>
>> But it would rather convoluted: the best idea I have so far is to
>> mangle methods name in the manner most of C++ compilers do.[/color][/color]

PEAK has a fairly sophisticated implementation of method dispatch you may want
to look at.

http://peak.telecommunity.com/Articles/WhatisPEAK.html
http://dirtsimple.org/2004/11/generi...ve-landed.html
http://peak.telecommunity.com/doc/sr.../__init__.html

I'm compelled to point out that PEAK should still be considered a 'work in
progress', but PJE's ideas should help you out :)

Cheers,
Nick.

--
Nick Coghlan | ncoghlan@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
anton muhin
Guest
 
Posts: n/a
#4: Jul 18 '05

re: multimethod (or rather overloading) in Python


Nick Coghlan wrote:[color=blue]
> anton muhin wrote:
>[color=green]
>> anton muhin wrote:
>>
>> Correction:
>>[color=darkred]
>>> Of course, I can imagine some metaclasses magic that would allow to
>>> code:
>>>
>>> class MyClass(WithOverloading):
>>> @overloadMethod(A)
>>> def someMetod(self, _): ...
>>>
>>> But it would rather convoluted: the best idea I have so far is to
>>> mangle methods name in the manner most of C++ compilers do.[/color][/color]
>
>
> PEAK has a fairly sophisticated implementation of method dispatch you
> may want to look at.
>
> http://peak.telecommunity.com/Articles/WhatisPEAK.html
> http://dirtsimple.org/2004/11/generi...ve-landed.html
> http://peak.telecommunity.com/doc/sr.../__init__.html
>
> I'm compelled to point out that PEAK should still be considered a 'work
> in progress', but PJE's ideas should help you out :)
>
> Cheers,
> Nick.
>[/color]

Thank you very much, Nick!

anton.
Closed Thread