Re: A proposal to modify `None` so that it hashes to a constant

I stand by what I said, there is absolutely nothing disingenious about it.

> Over on the Discuss threads, 
> you have made it clear that the primary reason why you want hash(None) 
> to return a constant value is so that set iteration order will be 
> consistent from one run to another.
No, it's so the entire program behaves the same the next time I run it on the same data.
There is nothing wrong with what sets are doing, it's the hashing function that injects non-determinism, in this case for no good reason at all.

Again, for the n'th time, read what I wrote above:
Under this definition, sets in Python are deterministic, and _always_ have been.

I was just stating a fact, same as it is in all other languages I know. You are welcome to verify it by the way, if you can.
That's why I don't request any change from set. It works fine and always has.

>  you have barely mentioned that the same applies to 
> Ellipsis and NotImplemented
That's wrong, I did address that many times. What makes None special is that Optional as it is implemented in Python (`T | None`) relies on `None` for one of its possible states, and `Optional` fields are in common use on key types that perform structural hashing

I'd also change other sentinels to hash to a constant if it were up to me to decide, but there is no practical significance to that so I don't bother dying on that hill (especially now, given the mob reaction). That doesn't make my argument inconsistent in any way. Sorry.

> Let's consider a thought-experiment: suppose we agree to your proposal 
> to make hash(None) return a constant, but at the same time modify the 
> set iteration algorithm so that it starts from a different position each 
> time you iterate, making set iteration order even more unpredictable and 
> deterministically chaotic than it is now.

I address this already. I said it is a strongly unlikely FUD scenario. Sets have been behaving deterministically for decades now,  across all languages. There's a pretty good reason for that, even if this reason doesn't happen to be codified into the requirements of Python. So as I said, I will take my chances. 

Again it's something I already addressed here:
> Yes, in theory it is possible that a new version or implementation of Python will make sets non-deterministic - shuffle
> themselves in the background independently from their history of operations, or what have you
> and then my change loses all > of its value
> Like I said, anything is possible. But I think these last two points are essentially FUD.

_Please_ stop reiterating the same argument over and over and pretending I didn't already make a case against it. It doesn't help, just turns this discussion into a shouting match.