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.
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:42 | admin | set | github: 48767 |
| 2008年12月05日 15:29:44 | georg.brandl | set | status: open -> closed resolution: fixed messages: + msg77030 |
| 2008年12月05日 15:21:39 | LambertDW | set | messages: + msg77029 |
| 2008年12月05日 14:45:15 | georg.brandl | set | messages: + msg77021 |
| 2008年12月04日 04:38:59 | LambertDW | set | messages: + msg76868 |
| 2008年12月04日 04:34:58 | LambertDW | create | |