[Python-Dev] Call PyType_Ready on builtin types during interpreter startup? (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sun Dec 28 13:09:44 CET 2008

Nick Coghlan wrote:

Nick Coghlan wrote:

Is there a specific reason for not fully initialising the builtin types? Or should we be calling PyTypeReady on each of them from PyBuiltinInit? I need to correct this slightly: some builtin types are initialised properly by PyReadyTypes. So the question is actually whether or not the missing builtin types should be added to that function.

I'm probably going to fix the specific problem with hashing of range objects in Py3k just by initialising xrange/range properly in _Py_ReadyTypes.

However, I wonder how many other builtin types have the same problem - for example, the enumerate type is also missing a call to PyType_Ready:

Python 3.1a0 (py3k, Dec 14 2008, 21:35:11) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

x = enumerate([]) hash(x) Traceback (most recent call last): File "", line 1, in TypeError: unhashable type: 'enumerate' enumerate.name # implicit call to PyTypeReady 'enumerate' hash(x) -1212398692

Rather than playing whack-a-mole with this, does anyone have any ideas on how to systematically find types which are defined in the core, but are missing an explicit PyType_Ready call? (I guess one way would be to remove all the implicit calls in a local build and see what blows up... that seems a little drastic though)

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list