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!
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:"?
Yes to . 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.
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:42
admin
set
github: 48767
2008-12-05 15:29:44
georg.brandl
set
status: open -> closedresolution: fixedmessages: +