Most changes to Pythonrequire a NEWS entry.

Please add it using theblurb_it web app or theblurb command-line tool.

All commit authors signed the Contributor License Agreement.

None, likeTrue andFalse, is a special object in Python, and should have either a constant hash, or one that can be set by specifying the random hash seed.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phraseI have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

There is some value in making it dependent on the hash secret (PYTHONHASHSEED):

• for intentional fuzzing purposes
• it addresses these nebulous concerns I've seen on the discuss forum, that people might start unwittingly depending on the specific constant value of this hash

The cost of doing that is an extra global variable and a single calculation done once upon setting the hash secret. I think that is a reasonable cost - I'll try writing it that way.

EDIT: now that I did, having second thoughts - it's a larger change to CPython, and perhaps people who run their code only on platforms with ASLR disabled today will be surprised by the "non-determinism by default" we'll be introducing here.

The hash secret was introduced to negate chosen input complexity attacks on builtin hash sets/maps, which is not relevant here, as None is a singleton. The "fuzzing" use case is secondary.

I'm willing to go with either solution. Personally, I will benefit more from the PYTHONHASHSEED dependent hash, but I don't know that it's the right thing to do for general use.

Most changes to Pythonrequire a NEWS entry.

Please add it using theblurb_it web app or theblurb command-line tool.

✅ Deploy Preview forpython-cpython-preview canceled.

Most changes to Pythonrequire a NEWS entry.

Please add it using theblurb_it web app or theblurb command-line tool.

I'm waiting with the blurb update until we make a final decision whether to go with a hash-secret-dependent calculation or not.

I have made the requested changes; please review again

Thanks for making the requested changes!

@ethanfurman: please review the changes made to this pull request.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phraseI have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

The constant was chosen basically at whim (that particular value amused me); it's easier to implement as a constant because if we went with a random number we would have to make it contingent on the hash seed used to randomizestr andbyte hashes so that different runs of a program could be consistent (a virtual necessity for bug-hunting).

If it was a truly random value (which it currently is if Python was compiled with ASLR), then program results can vary from one run to the next with no way to force them to be the same (sinceNone's hash is not currently dependent on thePYTHONHASHSEED).

it's easier to implement as a constant because if we went with a random number we would have to make it contingent on the hash seed used to randomizestr andbyte hashes so that different runs of a program could be consistent (a virtual necessity for bug-hunting).

I just meant constant random number, like0xb1f921305a6be69e.

Since hashtable (dict and set) uses lower bits first, filling some lower bits can reduce hash collision against small constant ints.

But this is not a big issue because None is just one singleton.

I just meant constant random number, like 0xb1f921305a6be69e.

Just noting that if a 64-bit literal is used, we'd presumably need to add a static check for 32-bit builds, and add a 32-bit "fallback" value for that case.

Good point. Let's just use a 32-bit number instead.

Actually, unless I'm missing something, that is a 32-bit number.

I think that was in response to Inada-san's suggestion of0xb1f921305a6be69e.

Ah, that's what I was missing. I wish we had a reply directly to a comment ability. :-(

Thank you for this, it allowed to make my project deterministic!

I dropped a comment about it there:https://stackoverflow.com/questions/7681786/how-is-hashnone-calculated/75296606#75296606

Is this merged into 3.12? There's no mention in thechangelog.

Is this merged into 3.12? There's no mention in thechangelog.

The PR did update the blurb, and it appears ingit log when I check out branch 3.12.

What makes a given PR worthy of appearing in the changelog?
This one is not part of any PEP, nor was it planned work, or something that affects any language requirements. There is no contractual obligation that the hash will stay constant in the future, or that sets will continue to have iteration stability if used with deterministic hashes.