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 at wraparound)? Would the hash value changes happen only in "wraparound (= subtraction + of 2**(bits_in_long)) by incrementing" cases? Would hash(-1) become -1? Sorry to ask all that, but my C (and maths) is (are) *very* limited. I guess an invalid hash value is the reason to have hash(-1) == hash(-2) == -2 currently, if so the period would have to skip that, right? I don't see the need for "y" and would chain some IFs (if x == -1 OR abs(x) == ULONG_MAX), but those are weak guesses. Maybe it's worth discussing this patch without linking its most important change (long hash becoming periodic) to Decimal: it would have many impacts beyond Decimal and is rather a core change (as opposed to Lib). Also, a recent discussion on hashing[2] shows that sometimes the current behavior was well planned :) 1 - http://mail.python.org/pipermail/python-3000/2007-September/010374.html 2 - http://mail.python.org/pipermail/python-3000/2007-September/010327.html ---------- nosy: +ajaksu2 _____________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1772851> _____________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
