Nick Coghlan <ncogh...@gmail.com> added the comment: Ah, I think I figured it out - in 2.x, PyObject_Hash itself includes the fallback to _PyHash_Pointer if none of tp_hash, tp_compare or the tp_richcompare slots have been implemented on the type.
So long as a type is only trying to inherit object.__hash__ (as is the case with xrange), then this fallback will do the right thing if PyType_Ready hasn't been called yet. In 3.0, on the other hand, PyObject_Hash has no fallback - if tp_hash isn't filled in, the type isn't considered hashable. This means that for a type to properly inherit hashability in Py3k, PyType_Ready *must* be called on it. Probably the best thing to do is to add xrange and range to the list of types initialised in _Py_ReadyTypes in 2.x and 3.x respectively. _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4701> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
