it [randomising iteration order or sets] would also break the invariant that `repr(data) == repr(data)` but it is times like this that I feel that it would be worth it.
But it wouldn't -- equality of sets doesn't depend on iteration order. And even if you are talking about other types (this *is* a thought experiment), any type in which equality depends on order certainly shouldn't be jiggled in this way. And I think this is relevant -- I understand that it's handy that order be deterministic -- but even if it is made so in the current implementation, it still may not be consistent across different Python versions and implementations. Which is why I would think that relying on determinism of order is a bad idea anyway -- yes, the same computation should yield the same result -- but what does "same" mean? As far as sets go -- "same" is equality, and if you are checking anything else about them (such as iteration order), I think it's a mistake. Which I think is why Guido (or maybe someone else introduced the idea) was talking about order-preserving sets -- THAT would provide a larger benefit, and would change the specification of sets so that you *could* count on it across versions and implementations, like we can for the modern dict. So yes, the OP wasn't asking for that, but I think the point is that what the OP is asking for is not useful enough to do, whereas a larger proposal might be -- but only if it can be done without loss of performance, which, alas, no one knows how to do. Final confusion -- IIUC, even if the hash of None is made constant, you'd still need to turn off string hash munging to get deterministic order for sets with strings in them, yes? Which really seems to make this even less useful. -CHB On Tue, Nov 29, 2022 at 3:48 PM Steven D'Aprano <steve@pearwood.info> wrote:
On Tue, Nov 29, 2022 at 08:51:09PM -0000, Yoni Lavi wrote:
It does make your argument invalid though, since it's based on this assumption that I was asking for a requirement on iteration order (e.g. like dict's iteration order = insertion order guarantee), which is not the case.
Yoni, I think this answer is disingenious. 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.
Sure, you may *also* have some philosophical preference for None having a fixed hash, but you have barely mentioned that the same applies to Ellipsis and NotImplemented (and then only in passing), and that's not your driving motivation for this proposal.
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.
Would that satisfy you? From your posts on Discuss, I don't expect that you will be happy with this outcome.
Personally, and I don't expect that this will be a popular opinion, I wish that data structures that don't guarantee their iteration order would actively mix up their iteration order so that people wouldn't be tempted to rely on whatever accidental order they happen to get.
Sure, it would cost a little bit of code to implement, but think of the savings in unproductive arguments and discussions like this one :-(
It would also break the invariant that `repr(data) == repr(data)` but it is times like this that I feel that it would be worth it.
-- Steve _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/JIR4WQ5B... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython