-
-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
range objects becomes hashable after attribute access #48951
Comments
As reported by Dmitry Vasiliev on python-dev, a range object suddenly If I understand correctly, then the reason is that PyRange_Type doesn't I don't see any use for range objects being hashable, as they don't even |
You don't need to cast PyObject_HashNotImplemented to hashfunc |
Why does every other place seem to do the cast? Historical reasons? |
On Fri, Dec 19, 2008 at 2:02 PM, Hagen Fürstenau <report@bugs.python.org> wrote:
No, if you look at the functions being casted you will notice them do |
I'm talking about places like these: [hagenf@chage py3k]$ grep -R "(hashfunc)PyObject_HashNotImplemented" |
On Fri, Dec 19, 2008 at 2:14 PM, Hagen Fürstenau <report@bugs.python.org> wrote:
I have checked some of the examples you gave and noticed they were |
Here's an updated patch without the cast and a separate patch for |
The origin of the unnecessary hashfunc casts is just me following some I'll apply and backport Hagen's patches to 3.0 soon (as well as fixing |
OK, the discrepancy with bytearray turns out to be fairly Which then begs the question of why range() instances are unhashable Only at this point is the slot inheritance on the range() type |
Patch looks good to me. |
It has been pointed out to me that xrange() objects are hashable in 2.x, At that point the question becomes one of why xrange() is being |
Bumping to release blocker for 3.0.1 - until I understand this better, |
Ah, I think I figured it out - in 2.x, PyObject_Hash itself includes the So long as a type is only trying to inherit object.__hash__ (as is the In 3.0, on the other hand, PyObject_Hash has no fallback - if tp_hash Probably the best thing to do is to add xrange and range to the list of |
On the other hand, what is the use case for hashing objects whose Python 3.0 (r30:67503, Dec 4 2008, 06:47:38)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> range(10).__hash__
<method-wrapper '__hash__' of range object at 0x7f2d61dbd210>
>>> {range(10), range(10)}
{range(0, 10), range(0, 10)} I can see only confusion arising from that. |
Hagen Fürstenau wrote:
Fast membership testing in sets to track which objects you have and |
enumerate can be added to the list of builtin types which isn't |
Copied from python-dev post: Perhaps the path of least resistance is to change PyObject_Hash to be That approach would get us back to the Python 2.x status quo where |
I think that's the best thing to do. It would bring PyObject_Hash in If we pick some other solution (instead of modifying PyObject_Hash), |
Fixed using a lazy call to PyType_Ready in PyObject_Hash: 2.7: r68051 Forward-port to Py3k still to come. |
Forward port to 3.x: 3.1: r68058 |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: