On 12/16/19 6:30 PM, Tim Peters wrote:
If it's desired that "insertion order" be consistent across runs,
platforms, and releases, then what "insertion order" _means_ needs to
be rigorously defined & specified for all set operations. This was
comparatively trivial for dicts, because there are, e.g., no
commutative binary operators defined on dicts.
My intuition is that figuring out sensible semantics here is maybe not
trivial, but hardly impossible. If this proposal goes anywhere I'd be
willing to contribute to figuring it out.
If you want to insist that `a | b` first list all the elements of a,
and then all the elements of b that weren't already in a, regardless
of cost, then you create another kind of unintuitive surprise: in
general the result of "a | b" will display differently than the result
of "b | a" (although the results will compare equal), and despite that
the _user_ didn't "insert" anything.
Call me weird--and I won't disagree--but I find nothing unintuitive
about that. After all, that's already the world we live in: there are
any number of sets that compare as equal but display differently. In
current Python:
>>> a = {'a', 'b', 'c'}
>>> d = {'d', 'e', 'f'}
>>> a | d
{'f', 'e', 'd', 'a', 'b', 'c'}
>>> d | a
{'f', 'b', 'd', 'a', 'e', 'c'}
>>> a | d == d | a
True
This is also true for dicts, in current Python, which of course do
maintain insertion order. Dicts don't have the | operator, so I
approximate the operation by duplicating the dict (which AFAIK preserves
insertion order) and using update.
>>> aa = {'a': 1, 'b': 1, 'c': 1}
>>> dd = {'d': 1, 'e': 1, 'f': 1}
>>> x = dict(aa)
>>> x.update(dd)
>>> y = dict(dd)
>>> y.update(aa)
>>> x
{'a': 1, 'b': 1, 'c': 1, 'd': 1, 'e': 1, 'f': 1}
>>> y
{'d': 1, 'e': 1, 'f': 1, 'a': 1, 'b': 1, 'c': 1}
>>> x == y
True
Since dicts already behave in exactly that way, I don't think it would
be too surprising if sets behaved that way too. In fact, I think it's a
little surprising that they behave differently, which I suppose was my
whole thesis from the beginning.
Cheers,
//arry/
_______________________________________________
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/76LFOPFMT6EIQXAHBIQMI2EZRQAONTZ7/
Code of Conduct: http://python.org/psf/codeofconduct/
