homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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 2022年04月11日 14:56 by admin. 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
2022年04月11日 14:56:42adminsetgithub: 48767
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

AltStyle によって変換されたページ (->オリジナル) /