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
_______________________________________________
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/UTXX3FUQWCM2QVZYUPESG6FXTNESWO54/
Code of Conduct: http://python.org/psf/codeofconduct/
