This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients amaury.forgeotdarc, eric.smith, gpolo, hagen, ncoghlan, rhettinger
Date 2008-12-20.07:14:37
SpamBayes Score 4.6652385e-05
Marked as misclassified No
Message-id <1229757280.04.0.231257487234.issue4701@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2008-12-20 07:14:40ncoghlansetrecipients: + ncoghlan, rhettinger, amaury.forgeotdarc, eric.smith, gpolo, hagen
2008-12-20 07:14:40ncoghlansetmessageid: <1229757280.04.0.231257487234.issue4701@psf.upfronthosting.co.za>
2008-12-20 07:14:38ncoghlanlinkissue4701 messages
2008-12-20 07:14:38ncoghlancreate