[Tim]

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.

[Larry]

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.

No, it _is_ easy. It's just tedious, adding piles of words to the docs, and every constraint also constrains possible implementations. You snipped my example of implementing union, which you should really think about instead ;-)

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'}

Yup, it happens But under the sample union implementation I gave, it would never happen when the sets had different cardinalities (the different sizes are used to force a "standard" order then). For mathematical sets, | is commutative (it makes no difference to the result if the arguments are swapped - but can make a _big_ difference to implementation performance unless the implementation is free to pick the better order).

... 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)

Ya, it does, but I don't believe that's documented (it should be).

and using update.

Too different to be interesting here - update() isn't commutative. For sets, union, intersection, and symmetric difference are commutative.

... 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.

I appreciate that dicts and sets behave differently in visible ways now. It just doesn't bother me enough that I'm cool with slowing set operations to "fix that".