This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, benjamin.peterson, casevh, georg.brandl, jimjjewett, ked-tao, lemburg, loewis, mark.dickinson, pitrou, rhettinger, skip.montanaro, tim.peters
Date 2010-10-18.16:09:16
SpamBayes Score 0.00014673463
Marked as misclassified No
Message-id <>
In-reply-to <1287415644.3492.5.camel@localhost.localdomain>
On Mon, Oct 18, 2010 at 11:27 AM, Antoine Pitrou <> 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).
Date User Action Args
2010-10-18 16:09:19belopolskysetrecipients: + belopolsky, lemburg, tim.peters, loewis, skip.montanaro, georg.brandl, rhettinger, jimjjewett, mark.dickinson, pitrou, casevh, ked-tao, benjamin.peterson
2010-10-18 16:09:16belopolskylinkissue9778 messages
2010-10-18 16:09:16belopolskycreate