On Thu, Dec 19, 2019 at 9:57 PM Tim Peters <tim.pet...@gmail.com> wrote:
> > It's not obvious to me that insertion order is even the most obvious or > > most commonly relevant sort order. I'm sure it is for Larry's program, > but > > often a work queue might want some other order. Very often queues > > might instead, for example, have a priority number assigned to them. > > Indeed, and it makes me more cautious that claims for the _usefulness_ > (rather than just consistency) of an ordered set are missing an XY > problem. The only "natural" value of insertion-order ordering for a > dynamic ordered set is that it supports FIFO queues. Well, that's one > thing that a deque already excels at, but much more obviously, > flexibly, and space- and time- efficiently. I agree with Tim and David. Furthermore, I'd like to point out that the core built-in types are frequently archetypes or foundational paradigms for many derived concepts in 3rd-party libraries. Despite the fact that they have implementations, they also form a basis set of interfaces which are part of the lexicon of "Pythonic-ness". Something like a "set" is a very very common and useful base interface for programming. If we were to cloud or confound the (relatively clean) semantics around sets & set algebra by introducing ordinality, that same cloudiness will spread throughout the ecosystem. Unlike dict()s, which are a more computer science-y data structure with lots of details, sets are simple things with mathematical algebraic properties. These allow the user to compactly specify *what* they want done, without delving into the details of *how*. In my experience, this is always preferable, for ease of use, ease of learning, and correctness. Adding orderedness as a concern now imposes an additional cognitive burden onto the coder because they must be concerned with *how*. Ultimately, even if we establish that there is major utility in insertion-ordered sets, unordered sets also clearly have utility as well (as a more relaxed interface, with fewer promises). So in that case, which do we want as the default? I think about it like this: In a future time when sets maintain insertion order by default, every time I see library docs that require casting sets via collections.unordered_set() will feel like sand in the semantic vaseline. I would much rather have things the other way around. I don't really have a horse in this race, and I'm sure the dev community will arrive at a good resolution to this issue. However, I would just encourage folks to think less about "utility of the implementation", and more about "economy of semantics". As Larry pointed out earlier, ordered dicts posed a problem for MicroPython. This actually isn't a minor issue -- in the long run, forked semantics are a Bad Thing for the language (even for a language that is incorrectly eponymized with snakes!). -Peter
_______________________________________________ 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/EDWT5S3YIQ5UUEFDEWZHTV6YZJ3BNNKL/ Code of Conduct: http://python.org/psf/codeofconduct/
