Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
On Mon, Oct 18, 2010 at 11:27 AM, Antoine Pitrou <rep...@bugs.python.org> wrote: .. >> The benefit, though is that >> hash computations can be performed natively on the hash values without >> casting to an unrelated type. > > I don't understand what you mean by "native" and "unrelated". Signed > integers are not less native than unsigned ones. Sorry, I could have been clearer indeed. Consider the following code: static Py_hash_t long_hash(PyLongObject *v) { unsigned long x; ... x = x * sign; if (x == (unsigned long)-1) x = (unsigned long)-2; return (Py_hash_t)x; } Wouldn't it be cleaner if x was the same type as hash? Note that unsigned long is now wrong. What is needed is "unsigned integer type of the same size as Py_hash_t." If Py_hash_t has to stay signed, I think we should at least not rely of sizeof(Py_hash_t) to always remain the same as sizeof(size_t). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9778> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com