On Oct 6, 2021, at 10:53 AM, Finn Mason <email@example.com> wrote:
There’s tons of code that relies on dicts being ordered. Some just don’t know it. For example, dataclasses relies on ordered dicts.
I'm not a huge fan. Sure, dicts are ordered now, but I doubt that many people use that feature. I honestly still think of them as unordered ;)
I think we can rely on dicts being ordered as a language guarantee for the rest of time.
_______________________________________________Python-ideas mailing list -- firstname.lastname@example.orgTo unsubscribe send an email to email@example.com://mail.python.org/mailman3/lists/python-ideas.python.org/Message archived at https://firstname.lastname@example.org/message/3RKWSNOO4J7WJWBYFXMA7HKPBVZVIF3S/Code of Conduct: http://python.org/psf/codeofconduct/
Let's talk code clarity. After all, to quote GvR, "Code is more often read than written." (I may have gotten the wording wrong, I just wrote it off the top of my head.) To me, the presence of a dict suggests that order doesn't matter. If you want order, communicate that by using `collections.OrderedDict`, a fully-featured dict subclass where the point is the order! You can get the first or last key/item pairs with `.popitem()`. It works!
We could add indexing to OrderedDict, which would return key/value pairs. (While we're talking about collections, why don't we return a namedtuple ;) ) As for adding functions to `itertools`, sure, I'm for it. We don't need people writing `next(iter(iterable))` just to get the first item.
On Wed, Oct 06, 2021 at 11:11:09AM +0100, Alex Waygood wrote:
> > The temptation to insist "see, YAGNI!" at this point I shall resist.
> *You* might not need it, but I've seen it come up a lot on Stack
> Overflow, and all too often people end up going for the much less
> efficient solution. I personally have also written code with practical
> applications using `next(iter(mydict))`.
Under what circumstances do you care what the first key in a dict is,
without going on to care about the second, third, fourth etc?
They are surely extremely niche, or artificial, or both, e.g. the
Stackoverflow problem you link to: "find the first non-repeating
character in a string -- using only one loop". Why the *first* rather
than any, or all?
In any case, the presence of one or two uses for a piece of
functionality doesn't mandate that we make this a builtin. Your solution
with next() is perfectly adequate.
The other suggested methods are even more obscure. Why have a method
for returning the first value, without knowing the key?
"I don't know what the first key is, and I don't care, but I know that
whatever it is, it maps to the value 17."
Now what are you going to do with that knowledge? This seems like a
method in desperate need of a use-case.
> I agree that it's a lot of methods to add. That's precisely why I
> prefer Inada Naoki's suggestion of additions to itertools
Whether they are added to dict or itertools, there are still nine of
them, and they are pretty much near clones of each other:
# first_ and last_ whatsits
if you will excuse the misuse of hybrid Python/BNF syntax :-)
Python-ideas mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Message archived at https://email@example.com/message/T3TOFAFBPGY44LOVKSMVZJGBNQ7MUNEL/
Code of Conduct: http://python.org/psf/codeofconduct/