Repository navigation
__self__ on built-in functions is not as documented #58211
Description
Activity
SpecLad commented
on Feb 13, 2012 SpecLadmannequinMannequinAuthorThe language reference says this in section 3.2:
~
Built-in functionsA built-in function object is a wrapper around a C function. Examples of built-in functions are len() and math.sin() <...> Special read-only attributes: <...> __self__ is set to None (but see the next item) <...>.
~That is not the case:
ActivePython 3.2.2.3 (ActiveState Software Inc.) based on Python 3.2.2 (default, Sep 8 2011, 10:55:13) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> len.__self__ <module 'builtins' (built-in)> >>> open.__self__ <module 'io' (built-in)> >>> import math >>> math.sin.__self__ <module 'math' (built-in)>
It looks like this changed between 2.x and 3.x but the docs were not updated. None makes more sense than the module as __self__, though, so perhaps it is actually a bug. Then, again, since Python functions don't have a __self__, the __self__ of built-in functions seems like an anomaly to begin with...
It's nicer for introspection if __self__ is None on builtin functions. But fixing the docs is easier (and more backwards compatible).
Python-coded functions do not have .__self__. >>> def f(): pass >>> f.__self__ ... AttributeError: 'function' object has no attribute '__self__' Unbound builtin methods, which are simply builtins functions attached to a class, do not have .__self__ >>> list.__len__.__self__ ... AttributeError: 'wrapper_descriptor' object has no attribute '__self__'
So it makes no sense to me that builtin non-method functions should have this attribute.
"Built-in methods
This is really a different disguise of a built-in function, this time containing an object passed to the C function as an implicit extra argument. An example of a built-in method is alist.append(), assuming alist is a list object. In this case, the special read-only attribute __self__ is set to the object denoted by alist."should have 'method' replaced with 'instance method' as it is only talking about instance methods, as the term is used in the rest of the section. Or this section should be deleted as it duplicates the previous Instance Method section. Or it should be revised to actually discuss unbound builtin methods.
I think that functions in C modules are implemented as methods of module objects, which would explain why len.__self__ is builtins.
In Python 2 Py_InitModule4 optionally allows setting __self__ on module functions, but no module in the standard library actually uses this. It's always None. This is no longer optional with Python 3's PyModule_Create. Built-in module functions instantiated the normal way can be considered as methods of the module in which they're defined. However, some modules may specially instantiate functions for which __self__ is None, such as codecs.strict_errors.
>>> codecs.strict_errors.__self__ is None True15 remaining items
- added a commit that references this issue
on Apr 11, 2025 - added a commit that references this issue
on Apr 12, 2025 - added a commit that references this issue
on Apr 12, 2025 Oh my bad! I thought this was sufficient
@skirpichev @picnixz I intend to fix this on #113574 .
What do you guys think about something like:
__self__é definido paraNone. (CPython implementation detail: Nowadays, it has a different behaviour from that desired. See GH-58211 for more information.) See also built-in methods.The last sentence is to replace the currently unclear parenthesis.
I intend to fix this on
Ok.
What do you guys think about something like
I think we shouldn't mention GH requests/issues. Either lets properly document current behavior (see also closed issue #132299) or adjust it per docs.
I think we shouldn't mention GH requests/issues.
OK.
Either lets properly document current behavior (see also closed issue #132299) or adjust it per docs.
The problem is that the current CPython behavior doesn't match the expected one. Notice that the added tests are only CPython. If this behaviour changes in the future, it will fail, so this change will not pass unnoticed as a side effect of other changes, as @serhiy-storchaka said here.
What if we add an entry to the Test section of the changelog and mention it here?
Of course, we may do nothing. The problem is that this issue will continue to be open, and new duplicate issues will probably be opened.
The problem is that the current CPython behavior doesn't match the expected one.
In my experience, in such cases - implementation win, i.e. docs should be corrected.
Metadata
Metadata
Assignees
Projects
- Status
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs
__self__attribute of builtins functions (GH-113575) #132437