On Fri., 20 Dec. 2019, 2:58 am Tim Peters, <tim.pet...@gmail.com> wrote:
> [Nick Coghlan <ncogh...@gmail.com>] > > Starting with "collections.OrderedSet" seems like a reasonable idea, > > though - that way "like a built-in set, but insertion order preserving" > will > > have an obvious and readily available answer, and it should also > > make performance comparisons easier. > > Ya, I suggested starting with collections.OrderedSet earlier, but gave up > on it. > The problem is that the "use case" here isn't really a matter of > functionality, but of consistency: "it would be nice if", like dicts > enjoy now, the iteration order of sets was defined in an > implementation-independent way. That itch isn't scratched unless the > builtin set type defines it. > 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 to me to be worthy of a stdlib solution that doesn't force you to either separate a "job id" from the "job" object in an ordered dict, or else use an ordered dict with "None" values. So while it means answering "No" to the "Should builtin sets preserve order?" question (at least for now), adding collections.OrderedSet *would* address that "duplicate free pending task queue" use case. Cheers, Nick.
_______________________________________________ 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/HO4UDEFGPA4AIXDK4M3ITZIG2XWJ6XDM/ Code of Conduct: http://python.org/psf/codeofconduct/
