3 ms·
Especially with the (lack of) change to sets I'm interested to benchmark some regular things before and after the change. set(dict.keys()) set(dict.val
by lukeschlather 7y ago
Especially with the (lack of) change to sets I'm interested to benchmark some regular things before and after the change.
set(dict.keys())
set(dict.values())
thing1 = dict(...)
thing2 = copy.deepcopy(thing1)
I feel like there could be some other testcases. I'm wholly in support of the change (regardless of benchmarks) but depending on the results I could see some arguments against.
- masklinn 7y ago1. sets don't use the new dict's implementation 2. IIRC the new dicts are no(t significantly) slower than the old dicts, however they use less memory, and iterate faster The iteration order is actually a side-effect of implementation details, the original goals were a more compact representation and a faster iteration: https://mail.python.org/pipermail/python-dev/2012-December/123028.html https://mail.python.org/pipermail/python-dev/2012-December/1...
- lukeschlather 7y ago> 1. sets don't use the new dict's implementation Yes, of course. That's why I'm wondering if turning dict keys into a set is slower now.