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

[Adam Olsen]

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 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)

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