Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > strange __call__

Reply
Thread Tools

strange __call__

 
 
Rahul
Guest
Posts: n/a
 
      06-29-2005
Consider the following:
def a(x):
return x+1

def b(f):
def g(*args,**kwargs):
for arg in args:
print arg
return f(*args,**kwargs)
return g

a.__call__ = b(a.__call__)

now calling a(1) and a.__call__(1) yield 2 different results!!
i.e. for functions a(1) doesnt seem to be translated to a.__call__ if
you assign a new value to a.__call__?
i am using python 2.3.3
somebody please clear this confusion

 
Reply With Quote
 
 
 
 
Michael Hoffman
Guest
Posts: n/a
 
      06-29-2005
Rahul wrote:
> Consider the following:
> def a(x):
> return x+1
>
> def b(f):
> def g(*args,**kwargs):
> for arg in args:
> print arg
> return f(*args,**kwargs)
> return g
>
> a.__call__ = b(a.__call__)
>
> now calling a(1) and a.__call__(1) yield 2 different results!!
> i.e. for functions a(1) doesnt seem to be translated to a.__call__ if
> you assign a new value to a.__call__?


I don't know why this happens, but setting the __call__ attribute of a
is a pretty strange thing to do. Why not just set a instead? The
original function a(x) will still be stored as a closure in what is
returned from b().

If this is of purely academic interest then the answer is I don't know.
--
Michael Hoffman
 
Reply With Quote
 
 
 
 
Andreas Kostyrka
Guest
Posts: n/a
 
      06-29-2005
Just a guess, but setting "__X__" special methods won't work in most cases
because these are usually optimized when the class is created.

It might work if a.__call__ did exist before (because class a: contained
a __call__ definition).

Andreas

On Wed, Jun 29, 2005 at 09:15:45AM +0100, Michael Hoffman wrote:
> Rahul wrote:
> > Consider the following:
> > def a(x):
> > return x+1
> >
> > def b(f):
> > def g(*args,**kwargs):
> > for arg in args:
> > print arg
> > return f(*args,**kwargs)
> > return g
> >
> > a.__call__ = b(a.__call__)
> >
> > now calling a(1) and a.__call__(1) yield 2 different results!!
> > i.e. for functions a(1) doesnt seem to be translated to a.__call__ if
> > you assign a new value to a.__call__?

>
> I don't know why this happens, but setting the __call__ attribute of a
> is a pretty strange thing to do. Why not just set a instead? The
> original function a(x) will still be stored as a closure in what is
> returned from b().
>
> If this is of purely academic interest then the answer is I don't know.
> --
> Michael Hoffman
> --
> http://mail.python.org/mailman/listinfo/python-list

 
Reply With Quote
 
Rahul
Guest
Posts: n/a
 
      06-29-2005
Hi.
well if you do dir(a) just after defining 'a' then it does show
'__call__'.
the reason i wanted to do it is that i wanted to see if theres a
uniform way to wrap a function and callable objects so that for
example i can get some message printed whenever a function or a
function-like-object is called. then i could simply do :

def wrapper(obj):
g = obj.__call__
def f(*args,**kwargs):
for arg in argsrint arg
return g(*args,**kwargs)
obj.__call__=f
but it seems this will not work for functions


Andreas Kostyrka wrote:
> Just a guess, but setting "__X__" special methods won't work in most cases
> because these are usually optimized when the class is created.
>
> It might work if a.__call__ did exist before (because class a: contained
> a __call__ definition).
>
> Andreas
>
> On Wed, Jun 29, 2005 at 09:15:45AM +0100, Michael Hoffman wrote:
> > Rahul wrote:
> > > Consider the following:
> > > def a(x):
> > > return x+1
> > >
> > > def b(f):
> > > def g(*args,**kwargs):
> > > for arg in args:
> > > print arg
> > > return f(*args,**kwargs)
> > > return g
> > >
> > > a.__call__ = b(a.__call__)
> > >
> > > now calling a(1) and a.__call__(1) yield 2 different results!!
> > > i.e. for functions a(1) doesnt seem to be translated to a.__call__ if
> > > you assign a new value to a.__call__?

> >
> > I don't know why this happens, but setting the __call__ attribute of a
> > is a pretty strange thing to do. Why not just set a instead? The
> > original function a(x) will still be stored as a closure in what is
> > returned from b().
> >
> > If this is of purely academic interest then the answer is I don't know.
> > --
> > Michael Hoffman
> > --
> > http://mail.python.org/mailman/listinfo/python-list


 
Reply With Quote
 
Steven Bethard
Guest
Posts: n/a
 
      06-29-2005
Rahul wrote:
> def wrapper(obj):
> g = obj.__call__
> def f(*args,**kwargs):
> for arg in argsrint arg
> return g(*args,**kwargs)
> obj.__call__=f
> but it seems this will not work for functions


def wrap(obj):
def f(*args, **kwargs):
for arg in args:
print arg
return obj(*args, **kwargs)
return f

@wrap
def func(a, b, c):
...

class C(object):
...
C = wrap(C)

STeVe
 
Reply With Quote
 
Rahul
Guest
Posts: n/a
 
      06-29-2005
If you do C = wrap(C) C no longer remains a class..it becomes a
function.

Steven Bethard wrote:
> Rahul wrote:
> > def wrapper(obj):
> > g = obj.__call__
> > def f(*args,**kwargs):
> > for arg in argsrint arg
> > return g(*args,**kwargs)
> > obj.__call__=f
> > but it seems this will not work for functions

>
> def wrap(obj):
> def f(*args, **kwargs):
> for arg in args:
> print arg
> return obj(*args, **kwargs)
> return f
>
> @wrap
> def func(a, b, c):
> ...
>
> class C(object):
> ...
> C = wrap(C)
>
> STeVe


 
Reply With Quote
 
Reinhold Birkenfeld
Guest
Posts: n/a
 
      06-29-2005
Rahul wrote:
> If you do C = wrap(C) C no longer remains a class..it becomes a
> function.


Does that matter?

Reinhold
 
Reply With Quote
 
Steven Bethard
Guest
Posts: n/a
 
      06-29-2005
Steven Bethard wrote:
>
> def wrap(obj):
> def f(*args, **kwargs):
> for arg in args:
> print arg
> return obj(*args, **kwargs)
> return f
>
> @wrap
> def func(a, b, c):
> ...
>
> class C(object):
> ...
> C = wrap(C)


Rahul top-posted:
> If you do C = wrap(C) C no longer remains a class..it becomes a
> function.


And if you do
func = wrap(func)
which is the equivalent of
@wrap
def func(...):
...
then func no longer has the same signature. But as Reinhold suggests,
does that really matter? In the case of the class, you can still call
it to create class instances. In the case of the function, you can
still call it to retrieve return values. Why do you care about the type
of the object?

In the case that it does matter, e.g. you want to be able to invoke your
methods from the class instead of the instance, you can wrap the
specific function that you need wrapped, e.g.

class C(object):
@wrap
def __new__(cls, *args):
super(C, cls).__new__(cls, *args)
...

STeVe
 
Reply With Quote
 
Rahul
Guest
Posts: n/a
 
      06-29-2005
Hi.
I understood your point.
thanks...
rahul
Steven Bethard wrote:
> Steven Bethard wrote:
> >
> > def wrap(obj):
> > def f(*args, **kwargs):
> > for arg in args:
> > print arg
> > return obj(*args, **kwargs)
> > return f
> >
> > @wrap
> > def func(a, b, c):
> > ...
> >
> > class C(object):
> > ...
> > C = wrap(C)

>
> Rahul top-posted:
> > If you do C = wrap(C) C no longer remains a class..it becomes a
> > function.

>
> And if you do
> func = wrap(func)
> which is the equivalent of
> @wrap
> def func(...):
> ...
> then func no longer has the same signature. But as Reinhold suggests,
> does that really matter? In the case of the class, you can still call
> it to create class instances. In the case of the function, you can
> still call it to retrieve return values. Why do you care about the type
> of the object?
>
> In the case that it does matter, e.g. you want to be able to invoke your
> methods from the class instead of the instance, you can wrap the
> specific function that you need wrapped, e.g.
>
> class C(object):
> @wrap
> def __new__(cls, *args):
> super(C, cls).__new__(cls, *args)
> ...
>
> STeVe


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
changing __call__ on demand Stefan Behnel Python 11 02-14-2005 08:37 PM
Redefining __call__ in an instance Robert Ferrell Python 5 01-21-2004 09:34 PM
RE: Redefining __call__ in an instance Robert Brewer Python 1 01-16-2004 02:58 AM
newbie question, when __call__ method is used? chenyu Python 1 10-27-2003 05:26 AM
Why doesn't __call__ lead to infinite recursion? Patrick Lioi Python 7 08-19-2003 06:41 PM



Advertisments