[issue1772851] Decimal and long hash, compatibly and efficiently

Facundo Batista added the comment: Applied the patchs long_hash.patch (rev 58208) and decimal_hash_v2.patch (rev 58211) -- resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> ___

[issue1772851] Decimal and long hash, compatibly and efficiently

Mark Dickinson added the comment: And here's the updated decimal.__hash__ patch that goes with the long.__hash__ patch. _ Tracker <[EMAIL PROTECTED]>

[issue1772851] Decimal and long hash, compatibly and efficiently

Mark Dickinson added the comment: Here's a revised patch, that only touches longobject.c and does the minimum necessary to alter long.__hash__ from being *almost* completely predictable to being completely predictable. T

[issue1772851] Decimal and long hash, compatibly and efficiently

ajaksu added the comment: Thanks a lot for the explanation. I still think it could be valuable (C?)py3k change (but now for the predictability, as you say :) Regarding the performance of Decimal.__hash__: I believe (int) hash performance would be a moot issue if Decimal.__int__ was (much) fas

[issue1772851] Decimal and long hash, compatibly and efficiently

Mark Dickinson added the comment: To help explain what's going on, here's some Python code. The Python function long_hash1 below has the properties that: (1) long_hash1(n) == hash(n) for almost all integers n, with a very

[issue1772851] Decimal and long hash, compatibly and efficiently

ajaksu added the comment: IMHO this patch should be considered for (at least) py3k, in which long becomes the new int. As there is current interest in long/int performance[1] this seems like a good time to raise this kind of issue. Mark, could you please outline the semantic changes (specially