Home Original page

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

Steve Dower steve.dower at python.org
Tue Apr 23 11:13:32 EDT 2019 
On 23Apr2019 0034, Glenn Linderman wrote:
> On 4/22/2019 10:59 PM, Steve Dower wrote:
>> On 22Apr2019 2119, Glenn Linderman wrote:
>>> While Inada's suggested DictBuilder interface was immediately 
>>> obvious, I don't get how either copy or update would achieve the 
>>> goal. Perhaps you could explain? Particularly, what would be the 
>>> trigger that would make dict() choose to create a shared key 
>>> dictionary from the start? Unless it is known that there will be lots 
>>> of (mostly static) dictionaries with the same set of keys at the time 
>>> of creation of the first one, creating a shared key dictionary in 
>>> every case would cause later inefficiencies in converting them, when 
>>> additional items are added? (I'm assuming without knowledge that a 
>>> single shared key dictionary is less efficient than a single regular 
>>> dictionary.)
>>
>> Passing a dictionary to the dict() constructor creates a copy of that 
>> dictionary (as does copy.copy()). What other trigger do you need to 
>> decide "it contains the same keys"? It's a copy of the original dict, 
>> so by definition at that point it may as well share its entire 
>> contents with the original.
> 
> But if the original dictionary wasn't created with shared keys... the 
> copy can't share them either.  Or are you suggesting adding new code to 
> create a shared key dictionary from one that isn't?

This is a good point. Maybe dict.fromkeys() could do it? Or a 
sys.intern-like function (which is why I brought up that precedent). The 
point is to make it an optional benefit rather than strict 
language/library semantics.

Is there a cost to using a key sharing dict that is prohibitive when the 
keys aren't actually being shared?

Cheers,
Steve
More information about the Python-Dev mailing list