On Wed, Jul 08, 2020 at 05:44:00PM +0100, Stestagg wrote:
> So, use-case discussions aside, you get some pretty convincing performance
> wins even on small-ish dictionaries if direct indexing is used.
This reminds me of an anecdote my wife tells me about the days when she
was in a band in the USA. She and the roadies were travelling from a gig
in one city to another when she noticed a highway sign:
"Aren't we travelling the wrong way?"
To which the roadie driving answered "Who cares, we're making fantastic
time!"
Ah, the sixties.
Who cares if there's no practical use-cases for this feature, it's
really fast! *wink*
Assuming your timing tests are accurate (a lot of people don't time
their code well, and consequently get very inaccurate numbers) and
representative (timing is very sensitive to the combination of Python
version, OS, hardware, and load on the local machine) your results are
micro-benchmarks, the least helpful benchmarks.
For a dict with 15000 items, let us accept that your suggested:
mydict.items()[0]
is 5000 times faster than:
list(mydict.items())[0]
Conceded! But if you're only calling it *once*, who cares? It's still
only 3 milliseconds. My (hypothetical) script takes half a second to
run, I'm not going to notice 3ms.
What if I call it a thousand times?
Then I ought to make a list *once* and index the list repeatedly, not
keep making and throwing away the list, which gives me constant-time
random access to the items:
L = dict(mydict.items())
for i in indices:
L[i]
and I expect that list access is probably going to be faster than
mydict.items()[i] access. So now the cost of building the list is
amortized over a thousand calls, and becomes more or less invisible.
In my opinion, the reason why this proposal is not compelling include:
1. lack of a strong use-case;
2. inelegant semantic design that adds sequence-like behaviour to views
which are (imperfectly) designed to be set-like;
3. and concern that adding this to views would constrain future
performance improvements to the underlying dict.
(There may be others.)
Unless I have missed any others, we've only seen three use-cases:
(a) The original post wanted a full sequence API for dictionaries, with
the ability to insert keys at a specific index, not just get the N-th
key. Not going to happen.
(b) You've suggested "get any item", but that's probably better written
as `next(mydict.items)`.
(c) And `random.choice(mydict.items())` which seems to be lacking any
*concrete* use-case -- under what circumstances would we want this and
care about it's performance *enough* to add this to builtin dict views?
(It seems more like toy code we might write to illustrate the use of
indexed access than something with a concrete use-case behid it.)
If there was a really strong use-case, points 2 and 3 could be over-
ruled. But lacking a good use-case, the conservative safe choice here is
to keep the status quo and reject the proposal.
So I think that if you really want to champion this proposal, you would
be better off looking for concrete, practical use-cases and
macro-benchmarks, not micro.
--
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/SGKC4I5IHMXFGCIXYDXTMK5RHCN7VMKP/
Code of Conduct: http://python.org/psf/codeofconduct/
