[Python-Dev] Call PyType_Ready on builtin types during interpreter startup?

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 PyType_Ready on each of them from _PyBuiltin_Init?
> 
> I need to correct this slightly: some builtin types *are* initialised
> properly by _Py_ReadyTypes.
> 
> 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 "<stdin>", line 1, in <module>
TypeError: unhashable type: 'enumerate'
>>> enumerate.__name__ # implicit call to PyType_Ready
'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