On 4/22/2019 4:03 PM, Inada Naoki wrote:
On Tue, Apr 23, 2019 at 2:18 AM Chris Barker via Python-Dev
<python-dev@python.org> wrote:
On Fri, Apr 12, 2019 at 10:20 AM Brett Cannon <br...@python.org> wrote:
This doesn't strike me as needing an optimization through a dedicated method.
maybe a new dict mapping type -- "shared_dict" -- it would be used in places
like the csv reader where it makes sense, but wouldn't impact the regular dict at all.
you could get really clever an have it auto-convert to a regular dict when any
changes were made that are incompatible with the shared keys...
My current idea is adding builder in somewhere in stdlib (maybe collections?):
builder = DictBuilder(keys_tuple)
value = builder(values) # repeatedly called.
I don't want to add new mapping type because we already have shared key dict,
and changing mapping type may cause backward compatibility problem.
Regards,
As a heavy user of some self-written code that does stuff very similar
to csv reader, and creates lots of same-key dicts, I'd be supportive of
a performance enhancing solution here, although I haven't done a
detailed study of where the time is currently spent.
Is the problem that the existing shared key dict isn't always detected?
Or just that knowing in advance that it is expected to be a shared key
dict can save the detection work?
I do know that in my code, I have a complete list of keys and values
when I create each dict, and would be happy to tweak it to use the most
performance technique. The above looks like a nice interface, assuming
that values is expected to be in the same iterable order as keys_tuple
(but is there a need for keys_tuple to be a tuple? could it be any
iterable?).
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
