On Fri, Jul 31, 2020 at 04:30:22PM -0700, Guido van Rossum wrote:
So: dicts preserve order the dict_views preserve this same order
Some think that we can't call them "ordered", because somehow that implies other things, like the ability to insert, etc, but while I don't get that argument, fine, let's call them "order preserving".
Meh, who cares. (The confusion is usually between "ordered" and "sorted" but we're past that here, so let's just keep saying "ordered".)
I care, and I think other people should care too, because calling dicts "ordered" with no qualifying "by insertion order" provably confuses users. See for example the original poster who started this thread, who imagined that because dicts are now "ordered" he should be able to reorder the keys and insert keys in arbitrary positions. (That doesn't mean that every single reference to a dict's order needed to explicitly refer back to insertion order. I'm not unreasonably pedantic about this :-) [Christopher Barker]
1) Because adding ANYTHING new is taking on a commitment to preserve it in the future, and it's more code to write, maintain, and document. So regardless of any other argument, it shouldn't be added without a reasonable use case(s) -- what's reasonable is subjective, of course.
Agreed. It is much harder to remove unneeded functions than to add it, so we should be conservative about adding new functions. We should beware bloat and API creep.
2) Because it could be an "attractive nuisance" while dicts are order preserving, their internal structure is such that you cannot find the nth item without iterating through n items, making access O(n), rather than O(1) for access by key or access of the usual Sequences -- Folks expect numerical indexing to be O(1), so it could be tricky. However, the only other way to get an n'th item is to copy everything into a Sequence, which is a lot slower, or to use islice or next() to do the order N access by hand. So this is an attractive nuisance in the use case of wanting to take multiple items by index, in which case, making a sequence first would be better than directly accessing the dict_view object.
I'm not entirely sure that's a strong argument against this. I never really bought the argument that having O(N) indexing was bad because repeated indexing would then be O(N**2). That's true, but for small enough N everything is fast, and even O(N**3) or worse can be "fast enough" for small N. The builtins have plenty of other functions which are O(N), e.g. list.count, str.find etc. While one might build O(N**2) operations on top of those, typically people don't. So I think that, provided the underlying indexing access is "fast enough", which I daresay it would be, I don't think we should care too much about the risk of people writing technically O(N**2) code like: for i in range(len(mydict)): key = mydict.getkey(i) # get key by index This is no worse than what we can already write using existing list or string methods. Beginners can and do write much worse code, and professionals will learn better. -- Steven