__getattr__ and functions that don't exist

[Erik Johnson]

Maybe I just don't know the right special function, but what I am wanting to
do is write something akin to a __getattr__ function so that when you try to
call an object method that doesn't exist, it get's intercepted *along with
it's argument*, in the same manner as __getattr__ intercepts attributes
references for attributes that don't exist.


This doesn't quite work:
.... def __getattr__(self, att_name, *args):
.... print "%s%s" % (att_name, str(tuple(*args)))
....bar()
Traceback (most recent call last):
bar()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: 'NoneType' object is not callable


Is there some other special function like __getattr__ that does what I want?

Thanks,
-ej

 

[Nick Smallbone]

Maybe I just don't know the right special function, but what I am wanting to
do is write something akin to a __getattr__ function so that when you try to
call an object method that doesn't exist, it get's intercepted *along with
it's argument*, in the same manner as __getattr__ intercepts attributes
references for attributes that don't exist.


This doesn't quite work:

... def __getattr__(self, att_name, *args):
... print "%s%s" % (att_name, str(tuple(*args)))
...

The problem is that the call to f.bar happens in two stages: the
interpreter calls getattr(f, "foo") to get a function, and then it
calls that function. When __getattr__ is called, you can't tell what
the parameters of the function call will be, or even if it'll be called
at all - someone could have run "print f.bar".

Instead, you can make __getattr__ return a function. Then *that*
function will be called as f.bar, and you can print out its arguments
there:

class Foo:
def __getattr__(self, attr):
def intercepted(*args):
print "%s%s" % (attr, args)
return intercepted

 

[Erik Johnson]

Thanks for your reply, Nick. My first thought was "Ahhh, now I see. That's
slick!", but after playing with this a bit...
.... def __getattr__(self, attr):
.... def intercepted(*args):
.... print "%s%s" % (attr, args)
.... return intercepted
....__repr__()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: __repr__ returned non-string (type NoneType)


my thought is "Oooooh... that is some nasty voodoo there!" Especially
if one wants to also preserve the basic functionality of __getattr__ so that
it still works to just get an attribute where no arguments were given.

I was thinking it would be clean to maintain an interface where you
could call things like f.set_Spam('ham') and implement that as self.Spam =
'ham' without actually having to define all the set_XXX methods for all the
different things I would want to set on my object (as opposed to just making
an attribute assignment), but I am starting to think that is probably an
idea I should just simply abandon.

I guess I don't quite follow the error above though. Can you explain
exactly what happens with just the evaluation of f?

Thanks,
-ej

 

[George Sakkis]

Thanks for your reply, Nick. My first thought was "Ahhh, now I see. That's
slick!", but after playing with this a bit...

... def __getattr__(self, attr):
... def intercepted(*args):
... print "%s%s" % (attr, args)
... return intercepted
...
__repr__()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: __repr__ returned non-string (type NoneType)


my thought is "Oooooh... that is some nasty voodoo there!" Especially
if one wants to also preserve the basic functionality of __getattr__ so that
it still works to just get an attribute where no arguments were given.

I was thinking it would be clean to maintain an interface where you
could call things like f.set_Spam('ham') and implement that as self.Spam =
'ham' without actually having to define all the set_XXX methods for all the
different things I would want to set on my object (as opposed to just making
an attribute assignment), but I am starting to think that is probably an
idea I should just simply abandon.

You're right, you should probably abandon it because python is not
java; there's no reason to bloat your API with getters and setters
instead of the natural attribute access and assignment. Now if you've
spent a lot of time in the java camp and can't live without verbose
getters and setters, it's not hard to emulate them:

class Foo(object):
def __getattr__(self, attr):
if not (attr.startswith('get_') or attr.startswith('set_')):
raise AttributeError
name = attr[4:]
if attr[0] == 'g':
return lambda: getattr(self,name)
else:
return lambda value: setattr(self,name,value)

f = Foo()
f.set_bar(1)
print f.get_bar()
print f.bar

I guess I don't quite follow the error above though. Can you explain
exactly what happens with just the evaluation of f?

Several thing happen:
1. When you give an expression in the shell, its value is computed and
then passed to the repr() function. The result of repr(f) is what's
printed.
2. repr(f) attempts to call f.__repr__()
3. __repr__ is not defined in class Foo or any of its (zero)
superclasses.
4. As a result, f.__getattr__('__repr__') is called instead and returns
the intercept local function.
5. intercept() is called with zero arguments (remember, intercept is
the result of f.__repr__)
6. intecept prints something but it doesn't return explicitly; thus it
returns None.
7. There's a rule that __repr__ (like __str__ and __unicode__) has to
return a string-type (I'm not sure where is this rule enforced, by the
classobj maybe ?). Since you returned None, an exception is raised.

Note that there is not an exception if
- you replace print with return in __getattr__, or
- Foo is a new-style class, i.e. extends object like this:
class Foo(object):
# rest remain the same
The reason is that in step (3) above, __repr__ would be looked up in
Foo's superclass, object, and object.__repr__ would be called instead
of Foo.__getattr__. Try to use new-style classes in new code unless you
have a good reason not to.

 

[Ben Cartwright]

Thanks for your reply, Nick. My first thought was "Ahhh, now I see. That's
slick!", but after playing with this a bit...

... def __getattr__(self, attr):
... def intercepted(*args):
... print "%s%s" % (attr, args)
... return intercepted
...
__repr__()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: __repr__ returned non-string (type NoneType)


my thought is "Oooooh... that is some nasty voodoo there!" Especially
if one wants to also preserve the basic functionality of __getattr__ so that
it still works to just get an attribute where no arguments were given.

I was thinking it would be clean to maintain an interface where you
could call things like f.set_Spam('ham') and implement that as self.Spam =
'ham' without actually having to define all the set_XXX methods for all the
different things I would want to set on my object (as opposed to just making
an attribute assignment), but I am starting to think that is probably an
idea I should just simply abandon.

Well, you could tweak __getattr__ as follows:
.... def __getattr__(self, attr):
.... if attr.startswith('__'):
.... raise AttributeError
.... def intercepted(*args):
.... print "%s%s" % (attr, args)
.... return intercepted

But abandoning the whole idea is probably a good idea. How is defining
a magic set_XXX method cleaner than just setting the attribute? Python
is not C++/Java/C#. Accessors and mutators for simple attributes are
overkill. Keep it simple, you'll thank yourself for it later when
maintaining your code.

I guess I don't quite follow the error above though. Can you explain
exactly what happens with just the evaluation of f?

Sure. (Note, this is greatly simplified, but still somewhat complex.)
The Python interpreter does the following when you type in an
expression:

(1) evaluate the expression, store the result in temporary object
(2) attempt to access the object's __repr__ method
(3) if step 2 didn't raise an AttributeError, call the method, output
the result, and we're done
(4) if __getattr__ is defined for the object, call it with "__repr__"
as the argument
(5) if step 4 didn't raise an AttributeError, call the method, output
the result, and we're done
(6) repeat steps 2 through 5 for __str__
(7) as a last resort, output the default "<class __main__.Foo at
0xDEADBEEF>" string

In your case, the intepreter hit step 4. f.__getattr__("__repr__")
returned the "intercepted" function, which was then called. However,
the "interpreted" function returned None. The interpreter was
expecting a string from __repr__, so it raised a TypeError.

Clear as mud, right? Cutting out the __getattr__ trickery, here's a
simplified scenario (gets to step 3 from above):
... def __repr__(self):
... return None
... Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: __repr__ returned non-string (type NoneType)

Hope that helps! One other small thing... please avoid top posting.

--Ben

 

[bruno de chez modulix en face]

class Parrot(object):
class _dummy(object):
def __init__(self, obj, name):
self.name = name
self.obj = obj

def __call__(self, *args, **kw):
print "dummy %s for %s" % (self.name, self.obj)
print "called with %s - %s" % (str(args), str(kw))

def __getattr__(self, name):
return self._dummy(self, name)

hth

 

[Bruno Desthuilliers]

Erik Johnson a écrit :
(snip)

I was thinking it would be clean to maintain an interface where you
could call things like f.set_Spam('ham') and implement that as self.Spam =
'ham'

If all you want to do is to assign 'ham' to self.spam, just do it - no
need for a setter. And if you worry about possible future needs for
controlling assignement to spam, internally use another name for it or
any other computation at this level, then it will be time to refactor
obj.spam as a property:

class Parrot(object):
def _set_spam(self, value):
self._another_attrib = any_computation_here(value)
def _get_spam(self):
return some_more_processing_here(self._another_attrib)
spam = property(_get_spam, _set_spam)

p = Parrot()
p.spam = "ham"
print p.spam

without actually having to define all the set_XXX methods for all the
different things I would want to set on my object (as opposed to just making
an attribute assignment), but I am starting to think that is probably an
idea I should just simply abandon.

indeed.