(mixing together messages in the thread, sorry threaded-view readers)

[Nick]

I took Larry's request a slightly different way:

[...]

Only Larry can answer whether that would meet his perceived need.  My
_guess_ is that he wouldn't know OrderedSet existed, and, even if he
did, he'd use a dict with None values anyway (because it's less hassle
and does everything he wanted).

At last, something I can speak knowledgeably about: Larry's use case!  Regarding Larry, I'd say

1. his use case was small enough that almost anything maintaining order would have worked, even a list,
   
2. he often does have a pretty good idea what goodies are salted away in the Python standard library, and
3. a hypothetical collections.OrderedSet would probably work just fine.  And he'd probably use it too, as that makes the code clearer / easier to read.  If you read code using an OrderedSet, you know what the intent was and what the semantics are.  If you see code using a dict but setting the values to None, you think "that's crazy" and now you have a puzzle to solve.  Let's hope those comments are accurate!
   

Also, speaking personally, at least once (maybe twice?) in this thread folks have asked "would YOU, Mr Larry, really want ordered sets if it meant sets were slightly slower?"

The first thing I'd say is, I'm not sure why people should care about what's best for me.  That's sweet of you!  But you really shouldn't.

The second thing is, my needs are modest, so the speed hit we're talking about would likely be statistically insignificant, for me.

And the third thing is, I don't really put the set() API through much of a workout anyway.  I build sets, I add and remove items, I iterate over them, I do the occasional union, and only very rarely do I use anything else.  Even then, when I write code where I reach for a fancy operation like intersection or symmetric_difference--what tends to happen is, I have a rethink and a refactor, and after I simplify my code I don't need the fancy operations anymore.  I can't remember the last time I used one of these fancy operations where the code really stuck around for a long time.

So, personally?  Sure, I'd take that tradeoff.  As already established, I like that dict objects maintain their order, and I think it'd be swell if sets maintained their order too.  I suspect the performance hit wouldn't affect me in any meaningful way, and I could benefit from the order-maintaining semantics.  I bet it'd have other benefits too, like making regression tests more stable.  And my (admittedly uninformed!) assumption is, the loss of performance would mostly be in these sophisticated operations that I never seem to use anyway.

But I don't mistake my needs for the needs of the Python community at large.  I'd be mighty interested to read other folks coming forward and saying, for example, "please don't make set objects any slower!" and talking us through neat real-world use cases.  Bonus points if you include mind-boggling numbers and benchmarks!

As Larry pointed out earlier, ordered dicts posed a problem for MicroPython.

Just a minor correction: that wasn't me, that was Petr Viktorin.

Ten days left until we retire 2.7,

/arry