By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
464,570 Members | 999 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 464,570 IT Pros & Developers. It's quick & easy.

Re: proxy class and __add__ method

P: n/a
En Tue, 29 Jul 2008 13:13:51 -0300, Magnus Schuster
<ma************@yahoo.comescribi�:
Hello,
I have written the following small proxy class which I expect to pass all
function calls to the 'original' object:

--- BEGIN ---
class proxy(object):
def __init__( self, subject ):
self.__subject = subject
def __getattr__( self, name ):
return getattr( self.__subject, name )

prx_i=proxy(1)
print hasattr(prx_i,'__add__')
j=prx_i.__add__(1)
k=prx_i+1
--- END ---

Actually the "hasattr(prx_i,'__add__')" returns "True" as expected, and
"j=prx_i.__add__(1)" sets j=2.

But "k=prx_i+1" raises a
<type 'exceptions.TypeError'>: unsupported operand type(s) for +: 'proxy'
and 'int'.

How is this addition different from the previous line "j=..."? And how
can I
modify the proxy class so that all methods are passed on, which are not
explicitly overloaded?
__magic__ methods on new style classes are searched in the class, *not* in
the instance. prx_i+1 looks for __add__ in type(prx_i), that is, in the
proxy class. Try implementing a similar __getattr__ method in a metaclass.

--
Gabriel Genellina

Jul 30 '08 #1
Share this Question
Share on Google+
2 Replies

P: n/a
On Jul 29, 10:23*pm, "Gabriel Genellina" <gagsl-...@yahoo.com.ar>
wrote:
En Tue, 29 Jul 2008 13:13:51 -0300, Magnus Schuster *
<magnusschus...@yahoo.comescribi :
Hello,
I have written the following small proxy class which I expect to pass all
function calls to the 'original' object:
--- BEGIN ---
class proxy(object):
* * def __init__( self, subject ):
* * * * self.__subject = subject
* * def __getattr__( self, name ):
* * * * return getattr( self.__subject, name )
prx_i=proxy(1)
print hasattr(prx_i,'__add__')
j=prx_i.__add__(1)
k=prx_i+1
--- END ---
Actually the "hasattr(prx_i,'__add__')" returns "True" as expected, and
"j=prx_i.__add__(1)" sets j=2.
But "k=prx_i+1" raises a
<type 'exceptions.TypeError'>: unsupported operand type(s) for +: 'proxy'
and 'int'.
How is this addition different from the previous line "j=..."? And how *
can I
modify the proxy class so that all methods are passed on, which are not
explicitly overloaded?

__magic__ methods on new style classes are searched in the class, *not* in *
the instance. prx_i+1 looks for __add__ in type(prx_i), that is, in the *
proxy class.
This much is true.

Try implementing a similar __getattr__ method in a metaclass.
But I don't think they use __getattr__.. they bypass it. Effectively
they catch the assignment to __add__ and cache it. You'll have to
always define it in the class and have it be ineffectual in some cases.
Jul 30 '08 #2

P: n/a
En Wed, 30 Jul 2008 14:54:51 -0300, Rhamphoryncus <rh****@gmail.com>
escribió:
On Jul 29, 10:23*pm, "Gabriel Genellina" <gagsl-...@yahoo.com.ar>
wrote:
>En Tue, 29 Jul 2008 13:13:51 -0300, Magnus Schuster *
<magnusschus...@yahoo.comescribi :
I have written the following small proxy class which I expect to pass
all
function calls to the 'original' object:
--- BEGIN ---
class proxy(object):
* * def __init__( self, subject ):
* * * * self.__subject = subject
* * def __getattr__( self, name ):
* * * * return getattr( self.__subject, name )
But "k=prx_i+1" raises a
<type 'exceptions.TypeError'>: unsupported operand type(s) for +:
'proxy'
and 'int'.
How is this addition different from the previous line "j=..."? And
how *
can I
modify the proxy class so that all methods are passed on, which are not
explicitly overloaded?

Try implementing a similar __getattr__ method in a metaclass.

But I don't think they use __getattr__.. they bypass it. Effectively
they catch the assignment to __add__ and cache it. You'll have to
always define it in the class and have it be ineffectual in some cases.
Ouch, yes, thanks, I noticed the fact after some testing.

--
Gabriel Genellina

Jul 31 '08 #3

This discussion thread is closed

Replies have been disabled for this discussion.