(mixing together messages in the thread, sorry threaded-view readers)
On 12/19/19 3:15 PM, Tim Peters wrote:
[Nick]
I took Larry's request a slightly different way:
[...]
Only Larry can answer whether that would meet his perceived need. My
_guess_ is that he wouldn't know OrderedSet existed, and, even if he
did, he'd use a dict with None values anyway (because it's less hassle
and does everything he wanted).
At last, something I can speak knowledgeably about: Larry's use case!
Regarding Larry, I'd say
1. his use case was small enough that almost anything maintaining order
would have worked, even a list,
2. he often /does have/ a pretty good idea what goodies are salted away
in the Python standard library, and
3. a hypothetical collections.OrderedSet would probably work just
fine. And he'd probably use it too, as that makes the code clearer
/ easier to read. If you read code using an OrderedSet, you know
what the intent was and what the semantics are. If you see code
using a dict but setting the values to None, you think "that's
crazy" and now you have a puzzle to solve. Let's hope those
comments are accurate!
Also, speaking personally, at least once (maybe twice?) in this thread
folks have asked "would YOU, Mr Larry, really want ordered sets if it
meant sets were slightly slower?"
The first thing I'd say is, I'm not sure why people should care about
what's best for me. That's sweet of you! But you really shouldn't.
The second thing is, my needs are modest, so the speed hit we're talking
about would likely be statistically insignificant, for me.
And the third thing is, I don't really put the set() API through much of
a workout anyway. I build sets, I add and remove items, I iterate over
them, I do the occasional union, and only very rarely do I use anything
else. Even then, when I write code where I reach for a fancy operation
like intersection or symmetric_difference--what tends to happen is, I
have a rethink and a refactor, and after I simplify my code I don't need
the fancy operations anymore. I can't remember the last time I used one
of these fancy operations where the code really stuck around for a long
time.
So, personally? Sure, I'd take that tradeoff. As already established,
I like that dict objects maintain their order, and I think it'd be swell
if sets maintained their order too. I suspect the performance hit
wouldn't affect /me/ in any meaningful way, and I could benefit from the
order-maintaining semantics. I bet it'd have other benefits too, like
making regression tests more stable. And my (admittedly uninformed!)
assumption is, the loss of performance would mostly be in these
sophisticated operations that I never seem to use anyway.
But I don't mistake my needs for the needs of the Python community at
large. I'd be mighty interested to read other folks coming forward and
saying, for example, "please don't make set objects any slower!" and
talking us through neat real-world use cases. Bonus points if you
include mind-boggling numbers and benchmarks!
On 12/20/19 5:09 AM, Peter Wang wrote:
As Larry pointed out earlier, ordered dicts posed a problem for
MicroPython.
Just a minor correction: that wasn't me, that was Petr Viktorin.
Ten days left until we retire 2.7,
//arry/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/JYSJ55CWUE2FFK2K2Y75EWE7R7M6ZDGG/
Code of Conduct: http://python.org/psf/codeofconduct/
