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   |   ncogh...@gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to