homepage

In Python 3.3.0, several global `PyTypeObject`s are not initialized using PyType_Ready(...).
The list of uninitialized type objects::
 PyCapsule_Type
 PyLongRangeIter_Type
 PyFieldNameIter_Type
 PyFormatterIter_Type
 PySTEntry_Type
 PyCell_Type
 PyInstanceMethod_Type
 PyClassMethodDescr_Type
 PyMethodDescr_Type
 PyCallIter_Type
 PySeqIter_Type
 PyDictDummy_Type
Each of these can be verified using gdb::
 $ gdb -quiet python3.3
 Reading symbols from /opt/python/3.3.0/bin/python3.3...done.
 (gdb) break Py_Finalize
 Breakpoint 1 at 0x4a40a0: file Python/pythonrun.c, line 478.
 (gdb) run -c "pass"
 Starting program: /opt/python/3.3.0/bin/python3.3 -c "pass"
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
 Breakpoint 1, Py_Finalize () at Python/pythonrun.c:478
 478	 if (!initialized)
 (gdb) print PyCell_Type->tp_mro
 1ドル = (PyObject *) 0x0
(The list of uninitialized types was built by searching "info variables" in gdb to produce a list of PyTypeObjects. Those with <name>->tp_mro != NULL were treated as properly initialized. The remainder were further inspected by hand to throw out additional false positives, like those from modules which had been statically compiled into the Python binary).
I'm not sure if any of these actually need fixing, but for PyCell_Type this issue already resulted in one obscure bug: #16268.

New changeset eec0cafe171d by Benjamin Peterson in branch '3.2':
initialize more global type objects (closes #16369)
http://hg.python.org/cpython/rev/eec0cafe171d
New changeset 9371bf2287c4 by Benjamin Peterson in branch '3.3':
merge 3.2 (#16369)
http://hg.python.org/cpython/rev/9371bf2287c4
New changeset aa52d8559ce5 by Benjamin Peterson in branch 'default':
merge 3.3 (#16369)
http://hg.python.org/cpython/rev/aa52d8559ce5
New changeset 315bd0ceb97a by Benjamin Peterson in branch '2.7':
initialize more global type objects (closes #16369)
http://hg.python.org/cpython/rev/315bd0ceb97a 

New changeset abe8a2908f08 by Jesus Cea in branch '2.7':
Closes #16369: Global PyTypeObjects not initialized with PyType_Ready(...). DOCUMENT IT!
http://hg.python.org/cpython/rev/abe8a2908f08
New changeset e9ea7f6a7107 by Jesus Cea in branch '3.2':
Closes #16369: Global PyTypeObjects not initialized with PyType_Ready(...). DOCUMENT IT!
http://hg.python.org/cpython/rev/e9ea7f6a7107
New changeset 9a4e2d394ba0 by Jesus Cea in branch '3.3':
MERGE: Closes #16369: Global PyTypeObjects not initialized with PyType_Ready(...). DOCUMENT IT!
http://hg.python.org/cpython/rev/9a4e2d394ba0
New changeset e5f39546989f by Jesus Cea in branch 'default':
MERGE: Closes #16369: Global PyTypeObjects not initialized with PyType_Ready(...). DOCUMENT IT!
http://hg.python.org/cpython/rev/e5f39546989f 

Benjamin, 3.3/3.4 "PyDictDummy_Type" initialization is missing too. That code was introduced in 
"""
changeset: 76485:6e5855854a2e
user: Benjamin Peterson <benjamin@python.org>
date: Mon Apr 23 11:24:50 2012 -0400
summary: Implement PEP 412: Key-sharing dictionaries (closes #13903)
"""
Reopening and assigning to you :-) (if you don't want to work on this, let me know)

Any option of having a test?

It doesn't need to be initialized.

Even if not "needed" to be initialize, we might do it for regularity (no special cases are special enough :-). Or, if left alone, at least document it in the code.

New changeset e87d617cef23 by Benjamin Peterson in branch 'default':
make PyGrammar_LabelRepr return a const char * (closes #16369)
http://hg.python.org/cpython/rev/e87d617cef23 

Oops, that was supposed to go to #16375.