[ python-Bugs-1204734 ] Documentation error?

SourceForge.net noreply at sourceforge.net
Thu May 26 17:33:03 CEST 2005


Bugs item #1204734, was opened at 2005-05-19 01:21
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Eikenberry (zhar)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Documentation error?

Initial Comment:
>From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html

"Called unconditionally to implement attribute accesses for instances of the class. If the class also defines __getattr__, it will never be called (unless called explicitly)."

But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux.

class A(object):

    def __getattr__(self,key):
        print '__getattr__',key
        raise AttributeError,key

    def __getattribute__(self,key):
        print '__getattribute__',key
        raise AttributeError,key

a = A()
a.foo

$ python test.py
__getattribute__ foo
__getattr__ foo
Traceback (most recent call last):
  File "test.py", line 14, in ?
    a.foo
  File "test.py", line 7, in __getattr__
    raise AttributeError(key)
AttributeError: foo

It seems to be calling __getattribute__ as it should, but then it falls back on __getattr__ even though the docs specifically say it shouldn't.



----------------------------------------------------------------------

>Comment By: Terry J. Reedy (tjreedy)
Date: 2005-05-26 11:33

Message:
Logged In: YES 
user_id=593130

If the default __getattribute__ explicitly calls __getattr__ (but I 
don't know which source file to check), then the second 
sentence above *would* make some sense.

Guido (or deputy): what is your design intention?

Note: if the second sentence is kept, replacing 'it' with 'the latter' 
would make it clearer. I first read 'it' as referring to 
__getattribute__.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-05-24 05:08

Message:
Logged In: YES 
user_id=4771

I'll wait for an "authorized" confirmation, but so far I think that the current implementation is really how it is supposed to work.  The method 'object.__getattribute__' must be there, given that it is a common technique to use it directly in overridden __getattribute__ implementations.  As a consequence, __getattribute__ cannot completely shadow __getattr__, or __getattr__ would never be called.

----------------------------------------------------------------------

Comment By: John Eikenberry (zhar)
Date: 2005-05-23 14:43

Message:
Logged In: YES 
user_id=322022

Please specify in the documentation whether this is how it
is supposed to work or whether this is a side-effect of the
implementation. To make explicit if you can write code
relying on this 'feature' and not have it break at some point.

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-05-23 10:28

Message:
Logged In: YES 
user_id=4771

Indeed, the logic in typeobject.c is to call __getattribute__ and fall back on __getattr__ if the former raised an AttributeError.  This is necessary because all objects have a __getattribute__, actually, as there is one in the 'object' base class.  This let me think that the error is really in the documentation, which should mention this logic.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&group_id=5470


More information about the Python-bugs-list mailing list