Initialization is being done in PyType_GenericAlloc

[hvenev]

BPO	23869
Nosy	@ericsnowcurrently, @hvenev

^{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 = <Date 2018-06-13.16:21:39.907>
created_at = <Date 2015-04-04.15:03:22.175>
labels = ['interpreter-core', '3.7', '3.8']
title = 'Initialization is being done in PyType_GenericAlloc'
updated_at = <Date 2018-06-13.16:22:49.236>
user = 'https://github.com/hvenev'

bugs.python.org fields:

activity = <Date 2018-06-13.16:22:49.236>
actor = 'eric.snow'
assignee = 'none'
closed = True
closed_date = <Date 2018-06-13.16:21:39.907>
closer = 'eric.snow'
components = ['Interpreter Core']
creation = <Date 2015-04-04.15:03:22.175>
creator = 'h.venev'
dependencies = []
files = []
hgrepos = []
issue_num = 23869
keywords = []
message_count = 3.0
messages = ['240080', '319476', '319477']
nosy_count = 2.0
nosy_names = ['eric.snow', 'h.venev']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue23869'
versions = ['Python 3.5', 'Python 3.6', 'Python 3.7', 'Python 3.8']

[hvenev]

In PyType_GenericAlloc, the initialization is being done. Namely, the PyObject part of the object is initialized and it is tracked by the garbage collector.

In the documentation it is stated that tp_alloc should do no initialization.

[ericsnowcurrently]

Thanks for bringing this up, Hristo!

"Initialization" (in this context, and hopefully everywhere in the C-API docs) is referring specifically to setting fields on a custom instance, much as you would expect in __init__ (or sometimes even __new__). In that regard PyType_GenericAlloc does not do any initialization. Instead, what it does is at a low level which is consistent with allocating a basic object for use in the CPython object machinery:

• allocate the memory
• NULL out the allocated memory
• set initial refcount to 1
• fill in the fundamental PyObject fields (e.g. type)
• register with GC

Most of that relates directly to memory management and definitely belongs in PyType_GenericAlloc. I suppose you could argue that filling in the fundamental PyObject fields could go into PyType_GenericNew. However, doing so would leave the "allocated" object in an inconsistent state for the object machinery, to be resolved by the type's tp_new implementation. This could lead to problems for types that have a custom tp_new that does not use PyType_GenericNew. In that case moving anything from PyType_GenericAlloc to PyType_GenericNew would be a backward-incompatible change (and add complexity to the object creation workflow). Even though the chance for breakage is small, there would have to be a really strong reason to make such a change.

Consequently, there isn't a whole lot to be done here and I'm closing this issue. If I've misunderstood then please let us know. We can re-open the issue then.

FTR, PyType_GenericAlloc is implemented here:

https://github.com/python/cpython/blob/master/Objects/typeobject.c#L963

[ericsnowcurrently]

As to the docs, the entry for tp_alloc in Doc/c-api/typeobj.rst does not mention initialization. The tp_new entry does say that it should call tp_alloc and then do the minimum initialization possible. That implies (weakly) that tp_alloc should do the minimum initialization possible. Could you point me to the place where the docs talk about tp_alloc and initialization? That would be useful to see.

Regardless, having the tp_alloc entry explicitly say it shouldn't do any initialization does make sense. Feel free to open a separate issue on that.