All valid points, I'd recommend catching up on the entire thread, it'll be a lot quicker than re-iterating them here. The highly condensed tl;dr version is that list(d.items())[n] is sometimes the fastest option, but sometimes not, it's not always faster (sometimes many thousands of times slowe) nor the most readable version, but is more readable than the next(iter(dict.keys()) alternative that's been mooted. On Fri, Jul 10, 2020 at 2:20 PM Paul Moore <p.f.moore@gmail.com> wrote:
On Fri, 10 Jul 2020 at 13:47, Stestagg <stestagg@gmail.com> wrote:
The intent of my statement was: The current implementation of dict does not allow any reasonable implementation of dict_keys/dict_values/dict_items with O(1) index behaviour. I.e. the performance scalability of any future changes to the dict_* types that add direct indexing is *not* likely to be adversely affected by changes to the implementation of dict(), unless somehow iteration in O(n) time becomes impossible.
So you're saying that you'd like to be able to index dict.keys()/dict.values()/dict.items(), but are fine with O(n) performance.
OK,
list(d.items())[n]
does *precisely* what you are asking for. So you're asking for a less verbose spelling of that. That would be something we could discuss, except for the fact that
the_items = list(d.items()) the_items[n]
has *better* amortised performance than that, if I can index multiple times using the same snapshot of the list.
It's pretty much certain that you're not going to succeed if you are requesting a new dictionary feature that's guaranteed to have worse performance than the current idiomatic Python way of achieving the same result...
So either you are failing very badly at explaining what you want and why it's useful, or you should probably give up. Paul