__self__ on built-in functions is not as documented

[SpecLad]

BPO	14003
Nosy	@terryjreedy, @ezio-melotti, @merwok, @bitdancer, @voidspace, @anacrolix, @SpecLad, @eryksun, @vaultah, @DimitrisJim

^{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:

assignee = None
closed_at = None
created_at = <Date 2012-02-13.19:05:34.037>
labels = ['type-bug', '3.8', '3.9', '3.10', 'docs']
title = '__self__ on built-in functions is not as documented'
updated_at = <Date 2020-11-07.19:53:05.266>
user = 'https://github.com/SpecLad'

bugs.python.org fields:

activity = <Date 2020-11-07.19:53:05.266>
actor = 'iritkatriel'
assignee = 'docs@python'
closed = False
closed_date = None
closer = None
components = ['Documentation']
creation = <Date 2012-02-13.19:05:34.037>
creator = 'SpecLad'
dependencies = []
files = []
hgrepos = []
issue_num = 14003
keywords = []
message_count = 6.0
messages = ['153287', '153288', '153298', '153610', '153620', '244963']
nosy_count = 12.0
nosy_names = ['terry.reedy', 'ezio.melotti', 'eric.araujo', 'Arfrever', 'r.david.murray', 'michael.foord', 'anacrolix', 'docs@python', 'SpecLad', 'eryksun', 'vaultah', 'Jim Fasarakis-Hilliard']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue14003'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

Linked PRs

• gh-58211: Add tests for __self__ attribute of builtins functions #113575
• [3.13] gh-58211: Add tests for the __self__ attribute of builtins functions (GH-113575) #132437

[SpecLad]

The language reference says this in section 3.2:

~
Built-in functions

A 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)>

[bitdancer]

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...

[voidspace]

It's nicer for introspection if __self__ is None on builtin functions. But fixing the docs is easier (and more backwards compatible).

[terryjreedy]

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.

[merwok]

I think that functions in C modules are implemented as methods of module objects, which would explain why len.__self__ is builtins.

[eryksun]

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
    True

[skirpichev]

@picnixz, sorry. I don't think this should be closed: there is at least an apparent documentation issue. Docs says "__self__ is set to None (but see the next item)." for builtins. See also #132299.

[picnixz]

Oh my bad! I thought this was sufficient

[adorilson]

@skirpichev @picnixz I intend to fix this on #113574 .

What do you guys think about something like:

__self__ é definido para None. (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.

[skirpichev]

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.

[adorilson]

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.

[skirpichev]

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.