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.

classification
Title: Initialization is being done in PyType_GenericAlloc
Type: Stage: resolved
Components: Interpreter Core Versions: Python 3.8, Python 3.7, Python 3.6, Python 3.5
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: eric.snow, h.venev
Priority: normal Keywords:

Created on 2015-04-04 15:03 by h.venev, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (3)
msg240080 - (view) Author: Hristo Venev (h.venev) * Date: 2015-04-04 15:03
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.
msg319476 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2018-06-13 16:21
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
msg319477 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2018-06-13 16:22
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.
History
Date User Action Args
2022-04-11 14:58:15adminsetgithub: 68057
2018-06-13 16:22:49eric.snowsetmessages: + msg319477
2018-06-13 16:21:39eric.snowsetstatus: open -> closed

versions: + Python 3.7, Python 3.8, - Python 3.2, Python 3.3, Python 3.4
nosy: + eric.snow

messages: + msg319476
resolution: rejected
stage: resolved
2015-04-04 15:04:43h.venevsetcomponents: + Interpreter Core
versions: + Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
2015-04-04 15:03:22h.venevcreate