On 7/10/2020 9:20 AM, Paul Moore 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]
Or next(itertools.islice(d.items(), n, None))
There are multiple O(n) ways of doing this. If we're not going to require O(1), then I don't see the point of adding another ways of achieving the same thing. And I don't think we should require O(1): I wouldn't want to constrain any implementation for a niche use case.