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

strange __call__

P: n/a
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

Jul 19 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
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
Jul 19 '05 #2

P: n/a
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

Jul 19 '05 #3

P: n/a
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 args:print 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


Jul 19 '05 #4

P: n/a
Rahul wrote:
def wrapper(obj):
g = obj.__call__
def f(*args,**kwargs):
for arg in args:print 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
Jul 19 '05 #5

P: n/a
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 args:print 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


Jul 19 '05 #6

P: n/a
Rahul wrote:
If you do C = wrap(C) C no longer remains a class..it becomes a
function.


Does that matter?

Reinhold
Jul 19 '05 #7

P: n/a
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
Jul 19 '05 #8

P: n/a
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


Jul 19 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.