[Nick Coghlan <firstname.lastname@example.org>]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.