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

Adam Olsen rhamph at gmail.com
Sun Dec 28 21:59:07 CET 2008

On Sun, Dec 28, 2008 at 5:09 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

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 PyReadyTypes. However, I wonder how many other builtin types have the same problem - for example, the enumerate type is also missing a call to PyTypeReady: 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 PyTypeReady 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)

What I did with safethread was replace the implicit calls with assertions. That with the test suite should pick everything up.

-- Adam Olsen, aka Rhamphoryncus

More information about the Python-Dev mailing list