[Python-Dev] Proposal: dict.with_values(iterable)

[Glenn Linderman]

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 at python.org> wrote:
>> On Fri, Apr 12, 2019 at 10:20 AM Brett Cannon <brett at 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?).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190422/9942021f/attachment.html>