<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 4:03 PM, Inada Naoki
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAEfz+Tw=5whsoX9DYGof8cH7k11r+NWKAocdU+ZsufvHrH0QJw@mail.gmail.com">
      <pre class="moz-quote-pre" wrap="">On Tue, Apr 23, 2019 at 2:18 AM Chris Barker via Python-Dev
<a class="moz-txt-link-rfc2396E" href="mailto:python-dev@python.org"><python-dev@python.org></a> wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">
On Fri, Apr 12, 2019 at 10:20 AM Brett Cannon <a class="moz-txt-link-rfc2396E" href="mailto:brett@python.org"><brett@python.org></a> wrote:
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap="">

</pre>
          </blockquote>
          <pre class="moz-quote-pre" wrap="">This doesn't strike me as needing an optimization through a dedicated method.
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">
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...
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">

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,
</pre>
    </blockquote>
    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.<br>
    <br>
    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?<br>
    <br>
    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?).<br>
  </body>
</html>