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

[Nick Coghlan]

Some strangeness was recently reported for the range() type in Py3k
where instances are unhashable until an attribute is retrieved from the
range type itself, and then they become hashable. [1]

While there is definitely an associated bug in the range implementation
(it doesn't block inheritance of the default object.__hash__
implementation), there's also the fact that when the interpreter
*starts* the hash implementation hasn't been inherited yet, but it does
get inherited later.

It turns out that _PyBuiltin_Init doesn't call PyType_Ready on any of
the builtin types - they're left to have it called implicitly when an
operation using them needs tp_dict filled in.

Such operations (which includes retrieving an attribute from the type
object) will implicitly call PyType_Ready to populate tp_dict, which
also has the side effect of inheriting slot implementations from base
classes.

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?

Cheers,
Nick.

[1] http://bugs.python.org/issue4701

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