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. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BWJSBBQDN3C72OXO5XDD2PIJRCRJ4CG6/ Code of Conduct: http://python.org/psf/codeofconduct/
