super, decorators and gettattribute

[Richard Szopa]

Hello all,

I am playing around w/ Python's object system and decorators and I
decided to write (as an exercise) a decorator that (if applied to a
method) would call the superclass' method of the same name before
doing anything (initially I wanted to do something like CLOS
[1] :before and :end methods, but that turned out to be too
difficult).

However, I cannot get it right (specially, get rid of the eval). I
suspect that I may be misunderstandin g something happening between
super objects and __getattribute_ _ methods.

Here's my code:

def endmethod(fun):
"""Decorato r to call a superclass' fun first.

If the classes child and parent are defined as below, it should
work like:

>>x = child()
x.foo()

I am parent's foo
I am child's foo.
"""
name = fun.__name__
def decorated(self, *args, **kwargs):
try:
super_object = super(self.__cl ass__, self)

# now I want to achieve something equivalent to calling
# parent.foo(*arg s, **kwargs)
# if I wanted to limit it only to this example

# this doesn't work: in the example, it calls child's foo,
# entering in an eternal loop (instead of calling parent's
# foo, as I would expect).

# super_object.__ getattribute__( name)(*args, **kwargs)

# this does work, but I feel it's ugly
eval('super_obj ect.%s(*args, **kwargs)' % name)
except AttributeError:
pass # if parent doesn't implement fun, we don't care
# about it
return fun(self, *args, **kwargs) # hopefully none

decorated.__nam e__ = name
return decorated
class parent(object):
def foo(self):
print 'I am parent\'s foo'

class child(parent):
@endmethod
def foo(self):
print "I am foo\'s foo."

if __name__=='__ma in__':
x = child()
x.foo()

Can anybody tell me how to call a superclass method knowing its name?

Thanks in advance,
-- Richard

[1] http://en.wikipedia.org/wiki/Common_Lisp_Object_System

[Richard Szopa]

On Jan 12, 7:45 pm, Richard Szopa <ryszard.sz...@ gmail.comwrote:

doing anything (initially I wanted to do something like CLOS
[1] :before and :end methods, but that turned out to be too
difficult).

Erm, I meant :before and :after methods.

-- Richard

[Mike Meyer]

On Sat, 12 Jan 2008 10:45:25 -0800 (PST) Richard Szopa <ry***********@ gmail.comwrote:

Hello all,

I am playing around w/ Python's object system and decorators and I
decided to write (as an exercise) a decorator that (if applied to a
method) would call the superclass' method of the same name before
doing anything (initially I wanted to do something like CLOS
[1] :before and :end methods, but that turned out to be too
difficult).

However, I cannot get it right (specially, get rid of the eval). I
suspect that I may be misunderstandin g something happening between
super objects and __getattribute_ _ methods.

Here's my code:

def endmethod(fun):
"""Decorato r to call a superclass' fun first.

If the classes child and parent are defined as below, it should
work like:

>>x = child()
>>x.foo()

I am parent's foo
I am child's foo.
"""
name = fun.__name__
def decorated(self, *args, **kwargs):
try:
super_object = super(self.__cl ass__, self)

There's an apparently common bug here: you don't want to pass super
self.__class__, but the class that the method is bound to. The two
aren't the same, as an instance of a subclass will have the subclass
as self.__class__, and not the current class. So super will return the
current class or a subclass of it, meaning (since you invoked this
method from self) you'll wind up invoking this method recursively.
All of which means your decorator is probably going to have to take
the class as an argument.

# now I want to achieve something equivalent to calling
# parent.foo(*arg s, **kwargs)
# if I wanted to limit it only to this example

# this doesn't work: in the example, it calls child's foo,
# entering in an eternal loop (instead of calling parent's
# foo, as I would expect).

# super_object.__ getattribute__( name)(*args, **kwargs)

# this does work, but I feel it's ugly
eval('super_obj ect.%s(*args, **kwargs)' % name)
except AttributeError:
pass # if parent doesn't implement fun, we don't care
# about it
return fun(self, *args, **kwargs) # hopefully none

decorated.__nam e__ = name
return decorated
class parent(object):
def foo(self):
print 'I am parent\'s foo'

class child(parent):
@endmethod
def foo(self):
print "I am foo\'s foo."

if __name__=='__ma in__':
x = child()
x.foo()

Can anybody tell me how to call a superclass method knowing its name?

The same way you call any object's methods if you know it's name":

getattr(super_o bject, name)(*args, **kwargs)

The code seems to work the way you want:

>>x.foo()

I am parent's foo
I am foo's foo.

<mike
--
Mike Meyer <mw*@mired.or g> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

[Richard Szopa]

On Jan 12, 9:47 pm, Mike Meyer <mwm-keyword-python.b4b...@m ired.org>
wrote:

The same way you call any object's methods if you know it's name":

getattr(super_o bject, name)(*args, **kwargs)

Thanks a lot for your answer!

However, I am very surprised to learn that

super_object.__ getattr__(name) (*args, **kwargs)

getattr(super_o bject, name)(*args, **kwargs)

are not equivalent. This is quite odd, at least when with len()
and .__len__, str() and .__str__. Do you maybe know what's the
rationale behind not following that convention by getattr?

Best regards,

-- Richard

[Steven D'Aprano]

On Sat, 12 Jan 2008 15:47:05 -0500, Mike Meyer wrote:

There's an apparently common bug here: you don't want to pass super
self.__class__, but the class that the method is bound to.

Given an instance method, is it possible to easily determine what class
it is defined in?

I thought the im_class attribute might do it, but it apparently just
points to self.__class__.

>>class Foo(object):

.... def foo(self):
.... pass
....

>>class Bar(Foo):

.... def bar(self):
.... pass
....

>>Bar().bar.im_ class # expecting Bar

<class '__main__.Bar'>

>>Bar().foo.im_ class # hoping for Foo

<class '__main__.Bar'>

--
Steven

[Marc 'BlackJack' Rintsch]

On Sat, 12 Jan 2008 14:23:52 -0800, Richard Szopa wrote:

However, I am very surprised to learn that

super_object.__ getattr__(name) (*args, **kwargs)

getattr(super_o bject, name)(*args, **kwargs)

are not equivalent. This is quite odd, at least when with len()
and .__len__, str() and .__str__. Do you maybe know what's the
rationale behind not following that convention by getattr?

I think you are confusing `__getattr__` and `__getattribute __` here!
`getattr()` maps to `__getattr__()` , it's `__getattribute __` that's
different.

Ciao,
Marc 'BlackJack' Rintsch

[Richard Szopa]

On Jan 13, 8:59 am, Marc 'BlackJack' Rintsch <[e-mail] wrote:

On Sat, 12 Jan 2008 14:23:52 -0800, Richard Szopa wrote:

However, I am very surprised to learn that

super_object.__ getattr__(name) (*args, **kwargs)

getattr(super_o bject, name)(*args, **kwargs)

are not equivalent. This is quite odd, at least when with len()
and .__len__, str() and .__str__. Do you maybe know what's the
rationale behind not following that convention by getattr?

I think you are confusing `__getattr__` and `__getattribute __` here!
`getattr()` maps to `__getattr__()` , it's `__getattribute __` that's
different.

Well, in my code calling super_object.__ getattr__(name) (*args,
**kwargs) and getattr(super_o bject, name)(*args, **kwargs) gives
*different* effects (namely, the latter works, while the former
doesn't). That kinda suggests that they don't map to each other :-).
And that makes me feel confused.

Cheers,

-- Richard

[thebjorn]

On Jan 13, 1:51 pm, Richard Szopa <ryszard.sz...@ gmail.comwrote:

On Jan 13, 8:59 am, Marc 'BlackJack' Rintsch <[e-mail] wrote:

On Sat, 12 Jan 2008 14:23:52 -0800, Richard Szopa wrote:

However, I am very surprised to learn that

super_object.__ getattr__(name) (*args, **kwargs)

getattr(super_o bject, name)(*args, **kwargs)

are not equivalent. This is quite odd, at least when with len()
and .__len__, str() and .__str__. Do you maybe know what's the
rationale behind not following that convention by getattr?

I think you are confusing `__getattr__` and `__getattribute __` here!
`getattr()` maps to `__getattr__()` , it's `__getattribute __` that's
different.

Well, in my code calling super_object.__ getattr__(name) (*args,
**kwargs) and getattr(super_o bject, name)(*args, **kwargs) gives
*different* effects (namely, the latter works, while the former
doesn't). That kinda suggests that they don't map to each other :-).
And that makes me feel confused.

Cheers,

-- Richard

They do, except for when it comes to what super(..) returns. It isn't
really an object in the sense that they're presented in the tutorial,
but rather a sort of proxy to the methods in the ancestor classes of
the concrete object (self), relative to the current method's class. I
can't imagine that sentence would ease any confusion however, suffice
it to say that you have to call getattr(super(. .), 'name') instead of
super(..).__get attr__('name') and you have to call super(..).__len __()
instead of len(super(..)) -- I can't imagine that lessens any
confusion either :-/

super(..) is designed to handle situations like this correctly

class Root(object):
n = 1

class Left(Root):
def foo(self):
print 'n =', self.n
print 'super n = ', super(Left, self).n

class Right(Root):
n = 2

class Leaf(Left,Right ):
n = 3

x = Leaf()
x.foo()

the correct output is

n = 3
super n = 2
-- bjorn

[Richard Szopa]

On Jan 13, 3:31 pm, thebjorn <BjornSteinarFj eldPetter...@gm ail.com>
wrote:

They do, except for when it comes to what super(..) returns. It isn't
really an object in the sense that they're presented in the tutorial,
but rather a sort of proxy to the methods in the ancestor classes of
the concrete object (self), relative to the current method's class. I
can't imagine that sentence would ease any confusion however, suffice
it to say that you have to call getattr(super(. .), 'name') instead of
super(..).__get attr__('name') and you have to call super(..).__len __()
instead of len(super(..)) -- I can't imagine that lessens any
confusion either :-/

Surprisingly, I think your first sentence *does* make something more
clear. Let me check if I understand it right: when we call a method on
super(Foo, self) it is as if we were calling call-next-method in
Common Lisp or Dylan (i.e. the method of the class on the right of Foo
in self.mro()). This however does not imply for super to have its dict
the same as the class on the right of Foo---it remains the same as
self's dict.

However, there's one piece that doesn't completely fit to the puzzle:
why does getattr work? The help says:

getattr(...)
getattr(object, name[, default]) -value

Get a named attribute from an object; getattr(x, 'y') is
equivalent to x.y.
When a default argument is given, it is returned when the
attribute doesn't
exist; without it, an exception is raised in that case.

Does it work on the basis that "getattr(x, 'y') is equivalent to x.y"?
What is then a "named attribute for an object" in Python? It seems not
to be equivalent to the value of the item whose name is 'y' in the
object's class __dict__...

Cheers,

-- Richard

[Michele Simionato]

On Jan 14, 1:41 pm, Richard Szopa <ryszard.sz...@ gmail.comwrote:

However, there's one piece that doesn't completely fit to the puzzle:
why does getattr work? The help says:

getattr(...)
getattr(object, name[, default]) -value

Get a named attribute from an object; getattr(x, 'y') is
equivalent to x.y.
When a default argument is given, it is returned when the
attribute doesn't
exist; without it, an exception is raised in that case.

Does it work on the basis that "getattr(x, 'y') is equivalent to x.y"?
What is then a "named attribute for an object" in Python? It seems not
to be equivalent to the value of the item whose name is 'y' in the
object's class __dict__...

Cheers,

-- Richard

I really need to publish this one day or another, since these
questions
about super keeps coming out:

http://www.phyast.pitt.edu/~micheles/python/super.html