[Nick Coghlan <ncoghlan@gmail.com>]

I took Larry's request a slightly different way: he has a use case where
he wants order preservation (so built in sets aren't good), but combined
with low cost duplicate identification and elimination and removal of
arbitrary elements (so lists and collections.deque aren't good). Organising
a work queue that way seems common enough ...

Is it?  I confess I haven't thought of a plausible use case.  Larry
didn't really explain his problem, just suggested that an ordered set
would be "a solution" to it.

Here is the original description of my problem, from the original email in this thread.  I considered this an adequate explanation of my problem at the time.

I do have a use case for this. In one project I maintain a "ready" list of jobs; I need to iterate over it, but I also want fast lookup because I soemtimes remove jobs when they're subsequently marked "not ready".  The existing set object would work fine here, except that it doesn't maintain insertion order.  That means multiple runs of the program with the same inputs may result in running jobs in different orders, and this instability makes debugging more difficult.  I've therefore switched from a set to a dict with all keys mapped to None, which provides all the set-like functionality I need.

In subsequent emails I've clarified that my workloads are small enough--and computers are fast enough--that almost any data structure would work fine for me here, e.g. a list.  I don't think my needs should drive the decision making process regardless.  I only described my problem to get the conversation rolling.

I opine that anybody who iterates over set objects and has bugs in their code would appreciate set objects maintaining insertion order.  I suspect it would make their debugging easier, because given identical inputs their set iteration would behave identically, thus making their bugs that much more stable.  That's as much use case as I have for the feature.

/arry