[Python-ideas] Re: dict_items.__getitem__?
On 2021-10-06 at 08:52:22 -0600, Finn Mason wrote: > 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 > ;) +1 on still think of mappings as unordered (but finding myself screaming Get Off My Lawn more and more). I won't comment on popularity, except to note that there's a big part of me that thinks that it's popular for all the wrong reasons. I don't have any new arguments, but call me -1 on making mappings less distinct from lists, unless and until there is *no* performance penalty (space or speed) for using the former instead of the latter. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/M2GZ2OWWQO7LYDS6VBWGW3XJSMOOPU4Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict_items.__getitem__?
> On Oct 6, 2021, at 10:53 AM, Finn Mason wrote: > > > 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 ;) > 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 think we can rely on dicts being ordered as a language guarantee for the rest of time. Eric > 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! > > OrderedDict documentation: > https://docs.python.org/3.10/library/collections.html#collections.OrderedDict > > 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. > > > -- > Finn > >> On Wed, Oct 6, 2021, 8:02 AM Steven D'Aprano wrote: >> 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 >> next([iter|reversed](obj.[keys|values|items]())) >> >> if you will excuse the misuse of hybrid Python/BNF syntax :-) >> >> >> >> -- >> Steve >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/T3TOFAFBPGY44LOVKSMVZJGBNQ7MUNEL/ >> Code of Conduct: http://python.org/psf/codeofconduct/ > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/3RKWSNOO4J7WJWBYFXMA7HKPBVZVIF3S/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MNVUANOCFRG5JYRXKB546HVCCA2GRNNF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict_items.__getitem__?
On Wed, Oct 06, 2021 at 11:17:07AM -0400, Eric V. Smith wrote: > I think we can rely on dicts being ordered as a language guarantee for > the rest of time. Indeed. That's official and documented. "Changed in version 3.7: Dictionary order is guaranteed to be insertion order. This behavior was an implementation detail of CPython from 3.6." https://docs.python.org/3/library/stdtypes.html#mapping-types-dict If we were ever to make them unordered again, that would be a breaking change that would need to go through a full deprecation process. Given how serious that would be, it would be a **LONG** deprecation process, so it wouldn't happen until at least Python 5000. We're more likely to add new, specialised mapping types which may not be ordered, rather than breaking that guarantee for dicts. And even that is unlikely unless there is a pressing need for them in the stdlib. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FEUVNGJ5VO34U6EXSH6GZJZEMOU2UBZ3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict_items.__getitem__?
On Wed, Oct 6, 2021, 9:23 AM Ricky Teachey wrote: > On Wed, Oct 6, 2021 at 10:55 AM Finn Mason wrote: > >> 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've seen several people say this so I'll be a voice on the other side: I > am not a pro developer so my practices should probably not be weighted all > that much. But nevertheless, I have been constantly relying on order-ness > in regular dicts ever since it was non-official thing in cpython. I > actually did a little happy dance in my chair when RH announced this at > pycon years ago. > > I am sure I am not the only one. > > --- > Ricky. > > "I've never met a Kentucky man who wasn't either thinking about going home > or actually going home." - Happy Chandler > Perhaps I'm wrong about that. However, I would still like things relying on ordered dictionaries to be implemented in OrderedDict first. I might be alone in this opinion, though. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VEHD2ERZOYJDBLKZZX2XLBCXL55LPFB4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict_items.__getitem__?
On Wed, Oct 6, 2021 at 10:55 AM Finn Mason wrote: > 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've seen several people say this so I'll be a voice on the other side: I am not a pro developer so my practices should probably not be weighted all that much. But nevertheless, I have been constantly relying on order-ness in regular dicts ever since it was non-official thing in cpython. I actually did a little happy dance in my chair when RH announced this at pycon years ago. I am sure I am not the only one. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IMFYPRJAX2LJ5G6UERNADUZENHGP4FXI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict_items.__getitem__?
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 ;) 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! OrderedDict documentation: https://docs.python.org/3.10/library/collections.html#collections.OrderedDict 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. -- Finn On Wed, Oct 6, 2021, 8:02 AM Steven D'Aprano wrote: > 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 > next([iter|reversed](obj.[keys|values|items]())) > > if you will excuse the misuse of hybrid Python/BNF syntax :-) > > > > -- > Steve > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/T3TOFAFBPGY44LOVKSMVZJGBNQ7MUNEL/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3RKWSNOO4J7WJWBYFXMA7HKPBVZVIF3S/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict_items.__getitem__?
+1. These would be handy for any iterable. It'll works on dict keys and values; bonus. On Wed, 2021-10-06 at 15:42 +0100, Alex Waygood wrote: > > Whether they are added to dict or itertools, there are still nine > > of > > them > > No, the suggestion was to add two functions to itertools (first() and > last(), which would work with any iterable, not just dicts), rather > than adding nine methods to the dict interface. This was precisely > why I was saying that I liked the itertools solution more. > > > On 6 Oct 2021, at 15:01, Steven D'Aprano > > wrote: > > > > 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 > > next([iter|reversed](obj.[keys|values|items]())) > > > > if you will excuse the misuse of hybrid Python/BNF syntax :-) > > > > > > > > -- > > Steve > > ___ > > Python-ideas mailing list -- python-ideas@python.org > > To unsubscribe send an email to python-ideas-le...@python.org > > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > > Message archived at https://mail.python.org/archives/list/python- > > id...@python.org/message/T3TOFAFBPGY44LOVKSMVZJGBNQ7MUNEL/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/OCVRRJPZQCQ6UKVKR4GQRJFWAUJNDFK6/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5EJWQFXWOERWNRF4QEIESGY3DPHZZFOA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict_items.__getitem__?
> Whether they are added to dict or itertools, there are still nine of > them No, the suggestion was to add two functions to itertools (first() and last(), which would work with any iterable, not just dicts), rather than adding nine methods to the dict interface. This was precisely why I was saying that I liked the itertools solution more. > On 6 Oct 2021, at 15:01, Steven D'Aprano wrote: > > 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 >next([iter|reversed](obj.[keys|values|items]())) > > if you will excuse the misuse of hybrid Python/BNF syntax :-) > > > > -- > Steve > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/T3TOFAFBPGY44LOVKSMVZJGBNQ7MUNEL/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OCVRRJPZQCQ6UKVKR4GQRJFWAUJNDFK6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict_items.__getitem__?
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 next([iter|reversed](obj.[keys|values|items]())) if you will excuse the misuse of hybrid Python/BNF syntax :-) -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/T3TOFAFBPGY44LOVKSMVZJGBNQ7MUNEL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict_items.__getitem__?
On Tue, Oct 05, 2021 at 08:45:55AM +0100, Alex Waygood wrote: > I think there definitely should be a more obvious way to do this > (specifically the first and last keys/values/items of a dictionary What's your use-case for caring what the first and last key in a dict is? > An anti-pattern you see quite often on Stack Overflow to > get the first key of a dictionary is something like the following: > > first_key = list(mydict.keys())[0] Example number 9758 of why not to trust everything you see on Stackoverflow :-) > Another possibility I've been wondering about was whether several > methods should be added to the dict interface: > > dict.first_key = lambda self: next(iter(self)) > dict.first_val = lambda self: next(iter(self.values())) > dict.first_item = lambda self: next(iter(self.items())) > dict.last_key = lambda self: next(reversed(self)) > dict.last_val = lambda self: next(reversed(self.values())) > dict.last_item = lambda self: next(reversed(self.items())) Not every *one* line function needs to be a builtin. > But I think I like a lot more the idea of adding general ways of doing > these things to itertools. How about some recipes? `next(iter(mydict))` etc is a simple, easy, memorable, readable, maintainable way to get what you want. Composition of simple operations is great! Not everything needs to be a named function: def addone(x): """Return x + 1. >>> addone(32) 33 """ return x + 1 -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/235UJMEIN64W2X7CNFIR3O6MXMPOQT2S/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict_items.__getitem__?
> 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))`. > I was +0 sympathetic to that until you posted this obvious extension > of the idea I don't see these dict methods as an "obvious extension" of the idea; I see them as unneeded/irrelevant *if* a more general way of doing this is added to itertools. > That's an awful lot of new methods to take advantage of what for many > applications of dict (in fact, *all* of my applications ever[1]) is an > irrelevant ordering. 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, and why I've never bothered starting a thread on the subject myself. But since the topic was being discussed after Erik started this thread, I thought I might mention the alternative solution that's been in the back of my head for a while. > [A]nyone who wants it can do it themselves: As I said in my previous message, the existing idiom (`next(iter(mydict))`) appears to be extremely non-obvious for beginners in Python, causing them to often go for much more inefficient options. No one is claiming "there is no way to do this" at present; the argument is that the best way to do this is, at present, *not sufficiently obvious*. > These defs do something undefined on unordered mappings (ie, not based > on dict), and may be dangerous in that sense. Excellent point (though note that my suggestion was to extend the dict interface, not the interface for all mappings). > In the current implementation, positional indexing is time-expensive Yes, that's exactly why I don't support Erik's original suggestion of positional indexing for dict.keys(), dict.values() and dict.items(), and why I *only* support easy ways of fetching the first/last object from the view. > I wonder if any code is being written obscurely to ensure that > keys get added to dicts in the "right" order I personally have used dictionaries as ordered sets in the past (skip to the last code snippet in this answer: https://codereview.stackexchange.com/a/264437/24517), and would object to this being called an "obscure" use of the data structure. It is, by now, both well-known and well-advertised in the documentation that dictionaries are guaranteed to maintain insertion order. It's obviously not how the data structure has historically been used, but I don't see how that makes it an invalid use of the data structure *now*. Why shouldn't users be expected to exploit an advertised feature of the language? > On 6 Oct 2021, at 10:29, Stephen J. Turnbull > wrote: > > Alex Waygood writes: > >> Whereas obviously, > > The temptation to insist "see, YAGNI!" at this point I shall resist. > >> a much better way (especially if it's a very large dictionary) is >> to do: >> first_key = next(iter(mydict)) > >> [Inada Naoki] >>> I think we can add `itertools.first()` for this idiom, and >>> `itertools.last()` for `next(iter(reversed(x)))` idiom. > > I was +0 sympathetic to that until you posted this obvious extension > of the idea: > >> I like this idea, a lot. Another possibility I've been wondering >> about was whether several methods should be added to the dict >> interface: >> dict.first_key = lambda self: next(iter(self)) >> dict.first_val = lambda self: next(iter(self.values())) >> dict.first_item = lambda self: next(iter(self.items())) >> dict.last_key = lambda self: next(reversed(self)) >> dict.last_val = lambda self: next(reversed(self.values())) >> dict.last_item = lambda self: next(reversed(self.items())) > > That's an awful lot of new methods to take advantage of what for many > applications of dict (in fact, *all* of my applications ever[1]) is an > irrelevant ordering. > > And anyone who wants it can do it themselves: > > def first_key(dct): return next(iter(dct)) > def first_val(dct): return next(iter(dct.values())) > def first_item(dct): return next(iter(dct.items())) > def last_key(dct): return next(reversed(iter(dct))) > def last_val(dct): return next(reversed(iter(dct.values( > def last_item(dct): return next(reversed(iter(dct.items( > > These defs do something undefined on unordered mappings (ie, not based > on dict), and may be dangerous in that sense. OTOH, I suspect the > methods will do the wrong thing with many ordered mappings based on > dict that support orders other than insertion order. > >> But I think I like a lot more the idea of adding general ways of >> doing these things to itertools. > > If you want to convince others, you really need to be more specific > about the requirements that lead you to this conclusion. In the > current implementation, positional indexing is time-expensive, much > more so than keeping an auxiliary
[Python-ideas] Re: dict_items.__getitem__?
Alex Waygood writes: > Whereas obviously, The temptation to insist "see, YAGNI!" at this point I shall resist. > a much better way (especially if it's a very large dictionary) is > to do: > > first_key = next(iter(mydict)) > [Inada Naoki] > > I think we can add `itertools.first()` for this idiom, and > > `itertools.last()` for `next(iter(reversed(x)))` idiom. I was +0 sympathetic to that until you posted this obvious extension of the idea: > I like this idea, a lot. Another possibility I've been wondering > about was whether several methods should be added to the dict > interface: > dict.first_key = lambda self: next(iter(self)) > dict.first_val = lambda self: next(iter(self.values())) > dict.first_item = lambda self: next(iter(self.items())) > dict.last_key = lambda self: next(reversed(self)) > dict.last_val = lambda self: next(reversed(self.values())) > dict.last_item = lambda self: next(reversed(self.items())) That's an awful lot of new methods to take advantage of what for many applications of dict (in fact, *all* of my applications ever[1]) is an irrelevant ordering. And anyone who wants it can do it themselves: def first_key(dct): return next(iter(dct)) def first_val(dct): return next(iter(dct.values())) def first_item(dct): return next(iter(dct.items())) def last_key(dct): return next(reversed(iter(dct))) def last_val(dct): return next(reversed(iter(dct.values( def last_item(dct): return next(reversed(iter(dct.items( These defs do something undefined on unordered mappings (ie, not based on dict), and may be dangerous in that sense. OTOH, I suspect the methods will do the wrong thing with many ordered mappings based on dict that support orders other than insertion order. > But I think I like a lot more the idea of adding general ways of > doing these things to itertools. If you want to convince others, you really need to be more specific about the requirements that lead you to this conclusion. In the current implementation, positional indexing is time-expensive, much more so than keeping an auxiliary list and using dct[lst[ndx]]. It could also allow timing attacks if used in security-sensitive code. And I wonder if any code is being written obscurely to ensure that keys get added to dicts in the "right" order, instead of keeping an explict, efficient, and reorderable auxiliary list of keys? Footnotes: [1] It's true that some code I import is probably improved because the developers don't waste time tracking down test failures in dict- based data structures. :-) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PKRY5SDH3D3YFOWX2QVUHXKW2QK5DGDY/ Code of Conduct: http://python.org/psf/codeofconduct/
