<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#330033" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 4/22/2019 10:59 PM, Steve Dower
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c8698b9a-59d3-5de7-813a-f3a96cb77b0b@python.org">On
22Apr2019 2119, Glenn Linderman wrote:
<br>
<blockquote type="cite">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.)
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
<br>
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?<br>
<blockquote type="cite"
cite="mid:c8698b9a-59d3-5de7-813a-f3a96cb77b0b@python.org">
<br>
Basically this is just a partial copy-on-write, where we copy
values eagerly - since they're almost certainly going to change -
and keys lazily - since there are known scenarios where they are
not going to be changed, but we'll pay the cost later if it turns
out they are.
<br>
<br>
Cheers,
<br>
Steve
<br>
<br>
</blockquote>
<br>
</body>
</html>