[issue4701] range objects becomes hashable after attribute access

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue4701] range objects becomes hashable after attribute access

Nick Coghlan added the comment: Forward port to 3.x: 3.1: r68058 3.0: r68060 -- resolution: -> fixed status: open -> closed ___ Python tracker ___ _

[issue4701] range objects becomes hashable after attribute access

Nick Coghlan added the comment: Fixed using a lazy call to PyType_Ready in PyObject_Hash: 2.7: r68051 2.6: r68052 Forward-port to Py3k still to come. ___ Python tracker ___

[issue4701] range objects becomes hashable after attribute access

Eric Smith added the comment: > Perhaps the path of least resistance is to change PyObject_Hash to be > yet another place where PyType_Ready will be called implicitly if it > hasn't been called already? I think that's the best thing to do. It would bring PyObject_Hash in line with PyObject_Form

[issue4701] range objects becomes hashable after attribute access

Nick Coghlan added the comment: Copied from python-dev post: Perhaps the path of least resistance is to change PyObject_Hash to be yet another place where PyType_Ready will be called implicitly if it hasn't been called already? That approach would get us back to the Python 2.x status quo where

[issue4701] range objects becomes hashable after attribute access

Nick Coghlan added the comment: enumerate can be added to the list of builtin types which isn't initialised correctly, as can the callable+sentinel iterator return from the 2-argument version of iter() and the default sequence iterator returned by iter() when given a type with both __len__ and _

[issue4701] range objects becomes hashable after attribute access

Nick Coghlan added the comment: Hagen Fürstenau wrote: > Hagen Fürstenau added the comment: > >> I don't believe there is any driving reason for them not to be hashable. > > On the other hand, what is the use case for hashing objects whose > equality is defined as object identity? Fast membe

[issue4701] range objects becomes hashable after attribute access

Hagen Fürstenau added the comment: > I don't believe there is any driving reason for them not to be hashable. On the other hand, what is the use case for hashing objects whose equality is defined as object identity? Python 3.0 (r30:67503, Dec 4 2008, 06:47:38) [GCC 4.3.2] on linux2 Type "help

[issue4701] range objects becomes hashable after attribute access

Nick Coghlan 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 t

[issue4701] range objects becomes hashable after attribute access

Nick Coghlan added the comment: Bumping to release blocker for 3.0.1 - until I understand this better, I'm not sure if the xrange->range hashing behaviour change between 2.x and 3.x is a type specific problem or a general issue in the implementation of the new approach to tp_hash inheritance for

[issue4701] range objects becomes hashable after attribute access

Nick Coghlan added the comment: It has been pointed out to me that xrange() objects are hashable in 2.x, and since these range objects are immutable, I don't believe there is any driving reason for them not to be hashable. At that point the question becomes one of why xrange() is being initiali

[issue4701] range objects becomes hashable after attribute access

Changes by Raymond Hettinger : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/pyt

[issue4701] range objects becomes hashable after attribute access

Raymond Hettinger added the comment: FWIW, xrange() is hashable in Py2.6. I believe it was intended that that carry over to Py3.0's range() objects. -- nosy: +rhettinger ___ Python tracker

[issue4701] range objects becomes hashable after attribute access

Amaury Forgeot d'Arc added the comment: Patch looks good to me. -- nosy: +amaury.forgeotdarc resolution: -> accepted ___ Python tracker ___ _

[issue4701] range objects becomes hashable after attribute access

Nick Coghlan added the comment: OK, the discrepancy with bytearray turns out to be fairly straightforward: bytearray overrides the comparison operations, so inheritance of the default object.__hash__ is automatically blocked. range() objects don't support comparison, so they inherit __hash__ whe

[issue4701] range objects becomes hashable after attribute access

Nick Coghlan added the comment: The origin of the unnecessary hashfunc casts is just me following some of the more specific examples of filling in the tp_hash slot too closely without checking if the cast was still needed. I'll apply and backport Hagen's patches to 3.0 soon (as well as fixing s

[issue4701] range objects becomes hashable after attribute access

Changes by Hagen Fürstenau : Removed file: http://bugs.python.org/file12401/rangehash2.patch ___ Python tracker ___ ___ Python-bugs-list mailin

[issue4701] range objects becomes hashable after attribute access

Changes by Hagen Fürstenau : Added file: http://bugs.python.org/file12403/rangehash3.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue4701] range objects becomes hashable after attribute access

Changes by Eric Smith : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue4701] range objects becomes hashable after attribute access

Changes by Hagen Fürstenau : Removed file: http://bugs.python.org/file12400/rangehash.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue4701] range objects becomes hashable after attribute access

Changes by Hagen Fürstenau : Added file: http://bugs.python.org/file12402/remove_casts.patch ___ Python tracker ___ ___ Python-bugs-list mailin

[issue4701] range objects becomes hashable after attribute access

Hagen Fürstenau added the comment: Here's an updated patch without the cast and a separate patch for removing the other casts. Added file: http://bugs.python.org/file12401/rangehash2.patch ___ Python tracker __

[issue4701] range objects becomes hashable after attribute access

Guilherme Polo added the comment: On Fri, Dec 19, 2008 at 2:14 PM, Hagen Fürstenau wrote: > > Hagen Fürstenau added the comment: > > I'm talking about places like these: > > [hag...@chage py3k]$ grep -R "(hashfunc)PyObject_HashNotImplemented" > Objects/*.c Modules/*.c > Objects/dictobject.c:

[issue4701] range objects becomes hashable after attribute access

Hagen Fürstenau added the comment: I'm talking about places like these: [hag...@chage py3k]$ grep -R "(hashfunc)PyObject_HashNotImplemented" Objects/*.c Modules/*.c Objects/dictobject.c: (hashfunc)PyObject_HashNotImplemented, /* tp_hash */ Objects/listobject.c: (hashfunc)PyObject_HashNotIm

[issue4701] range objects becomes hashable after attribute access

Guilherme Polo added the comment: On Fri, Dec 19, 2008 at 2:02 PM, Hagen Fürstenau wrote: > > Hagen Fürstenau added the comment: > > Why does every other place seem to do the cast? Historical reasons? > No, if you look at the functions being casted you will notice them do not take a pointer t

[issue4701] range objects becomes hashable after attribute access

Hagen Fürstenau added the comment: Why does every other place seem to do the cast? Historical reasons? ___ Python tracker ___ ___ Python-bugs-l

[issue4701] range objects becomes hashable after attribute access

Guilherme Polo added the comment: You don't need to cast PyObject_HashNotImplemented to hashfunc -- nosy: +gpolo ___ Python tracker ___ __

[issue4701] range objects becomes hashable after attribute access

Changes by Hagen Fürstenau : -- keywords: +patch Added file: http://bugs.python.org/file12400/rangehash.patch ___ Python tracker ___ __

[issue4701] range objects becomes hashable after attribute access

New submission from Hagen Fürstenau : As reported by Dmitry Vasiliev on python-dev, a range object suddenly becomes hash()able after an attribute access, e.g. by dir(). If I understand correctly, then the reason is that PyRange_Type doesn't set tp_hash and PyType_Ready is not normally called on