I recently realized that the output of the following is different between 32 bit and 64 bit architectures:

PYTHONHASHSEED=0 python3 -c 'print(hash("a"))'

In my case, I'm running some test cases which involve calling a Python module which creates several hundred megabyte big graphs and other things. The fastest way to make sure that the output I get is the same that I expect is to just call the md5sum or sha256sum shell tools on the output and compare them with the expected values. Unfortunately, some libraries I use rely on the order of items in Python dictionaries for their output. Yes, they should not do that but they also don't care and thus don't fix the problem.

My initial solution to this was to use PYTHONHASHSEED=0 which helped but I now found out that this is limited to producing the same hash within the set of 32 bit and 64 bit architectures, respectively. See above line which behaves different depending on the integer size of architectures.

So what I'd like CPython to have is yet another workaround like PYTHONHASHSEED which allows me to temporarily influence the inner workings of the hash() function such that it behaves the same on 32 bit and 64 bit architectures. Maybe something like PYTHONHASH32BIT or similar?

If I understand the CPython hash function correctly, then this environment variable would just bitmask the result of the function with 0xFFFFFFFF or cast it to int32_t to achieve the same output across architectures.

Would this be possible?

My only alternative seems to be to either maintain patched versions of all modules I use which wrongly rely on dictionary ordering or to go to great lengths of parsing the (more or less) random output they produce into a sorted intermediary format - which seems like a bad idea because the files are several hundred megabytes big and this would just take very long and require additional complexity in handling them compared to being able to just md5sum or sha256sum them for the sake of checking whether my test cases succeed or not.

While I can feel your pain regarding the use case you describe, I don't think this has enough general value to add to CPython.  It is not really related to PYTHONHASHSEED, since we never made guarantees about hash values being stable across platforms and Python versions.  PYTHONHASHSEED was introduced to address backwards compatibility for the rare cases where stable hash values are required within a platform/version combination.

Without knowing anything about your libraries, would it not be possible to create a stable representation within the test case for comparison purposes, without having to write the unstable result to a file and then parsing it?  That should be acceptable, given that creating and manipulating those graphs will probably also take significant time in the first place.

Thank you for your quick reply.

Yes, as I wrote above there are ways around it by creating a stable in-memory representation and comparing that to a stable in-memory representation of the expected output. Since both input are several hundred megabytes in size, this would be CPU intensive but do-able. I would've just likeld to avoid treating this output in a special way because I also compare other files and it is most easy to just md5sum all of the files in one fell swoop.

I started using PYTHONHASHSEED to gain stable output for a certain platform/version combination. When I uploaded my package to Debian and it was built on 13 different architectures I noticed the descrepancy when the same version but different platforms are involved.

From my perspective it would be nice to just be able to set PYTHONHASH32BIT (or whatever) and call it a day. But of course it is your choice whether you would allow such a "hack" or not.

Would your decision be more favorable if you received a patch implementing this feature?

> Would your decision be more favorable if you received a patch implementing this feature?

I'll keep this on "pending" for other devs to weigh in with opinions.

In general, we are not keen on keeping text representations stable, as they do not form part of the API.  This is true for exception messages most of all, but also the representations of other types change occasionally.  Doctests and other test methods that rely on exact output, such as yours, have to adapt to that.

The patch wouldn't be difficult to write, but the issue is more that it isn't really generally useful (as evidenced by the fact that you are the first to request it), and it won't save you a lot of work in any case if you want to support existing versions of Python (2.7, 3.x) as well: the new feature could only go into 3.5.

Like Georg I am sympathetic to the problem, but this is not the correct solution.

You might post a question on python-list to see if a usable, not-to-painful solution can be found.

> some libraries I use rely on the order of items in Python dictionaries for their output

Your choices are:

* create a custom hash function using __hash__
* or sort the output from within Python
* or sort the output externally, prior to diffing.

> From my perspective it would be nice to just be able 
> to set PYTHONHASH32BIT 

The odds of this being accepted are almost zero.
We're moving in the opposite direction of randomizing
the hash from run-to-run.