classification
Title: improve __getattribute__ documentation
Type: enhancement Stage:
Components: Documentation Versions: Python 3.0
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: georg.brandl Nosy List: LambertDW, georg.brandl
Priority: normal Keywords:

Created on 2008-12-04 04:34 by LambertDW, last changed 2008-12-05 15:29 by georg.brandl. This issue is now closed.

Messages (5)
msg76867 - (view) Author: David W. Lambert (LambertDW) Date: 2008-12-04 04:34
http://docs.python.org/dev/3.0/reference/datamodel.html#special-lookup

(After fixing the link to http://docs.python.org/3.0 at http://www.python.org/doc/ (and likewise the http://docs.python.org/whatsnew/3.0.html link.)...

The comment that __getattribute__ is "Called unconditionally to 
implement attribute accesses for instances of the class" gave me hope 
that some combination of "meta" "super" and "sub" might let me access 
__getattribute__ for expression eval('obj + another_object') despite the 
special notes.  I realize now the truth is that

"__getattribute__ is NEVER accessible in pure python code when the code 
uses the syntax of a unary or binary operator such as a+b, ~a, len(a)."
See most of the functions in this manual section.
Also name hash, which doesn't find much explicit use but could well be 
the most used python functionality.  Find a smooth way to replace my 
NEVER since code can obviously access __getattribute__ from the special 
function.

Thank you, and great work!
msg76868 - (view) Author: David W. Lambert (LambertDW) Date: 2008-12-04 04:38
>>> class c:
...  def __getattribute__(self,*args):
...   print('getattribute chimes in')
... 

>>> c()+3
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'c' and 'int'
msg77021 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-12-05 14:45
Isn't what you refer to covered by this paragraph and the following
example: "In addition to bypassing any instance attributes in the
interest of correctness, implicit special method lookup may also bypass
the __getattribute__() method even of the object’s metaclass:"?
msg77029 - (view) Author: David W. Lambert (LambertDW) Date: 2008-12-05 15:21
Yes to msg77021.  However!

I'll pin the difficulty specifically to the word "may".  This cost me a
lot of time.


1) Please change the phrasing you quoted to

"... implicit special method lookup bypasses the __getattribute__()
method even of the object’s metaclass:"


2) Please insert into the glossary a definition of "implicit special
method lookup" that addresses the grammar or syntax that causes it
considering monad and dyad use.


Thank you.
msg77030 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-12-05 15:29
I've changed "may bypass" to "generally bypasses". It doesn't happen for
all methods, but that's an implementation detail.

I've also added a glossary entry "special method" in r67579.
History
Date User Action Args
2008-12-05 15:29:44georg.brandlsetstatus: open -> closed
resolution: fixed
messages: + msg77030
2008-12-05 15:21:39LambertDWsetmessages: + msg77029
2008-12-05 14:45:15georg.brandlsetmessages: + msg77021
2008-12-04 04:38:59LambertDWsetmessages: + msg76868
2008-12-04 04:34:58LambertDWcreate