<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 7:27 PM, Steve Dower
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:25ca35f9-ae2b-ed4e-cb07-8d8fa87f6dbf@python.org">On
22Apr2019 1921, Steve Dower wrote:
<br>
<blockquote type="cite">On 22Apr2019 1822, Glenn Linderman wrote:
<br>
<blockquote type="cite">Inada is now proposing a way to allow
the coder to suggest a group of dictionaries that might
benefit from the same gains, by preclassifying non-__dict__
slot dictionaries to do similar sharing.
<br>
<br>
CSV reader is an exemplary candidate, because it creates
groups of dicts that use the same keys. (column names). I have
other code that does similar things, that would get similar
benefits.
<br>
<br>
Seems like since it is just an interface to existing builtin
code, that the one interface function (or dictionary factory
class) could just as well be a builtin function, instead of
requiring an import.
<br>
</blockquote>
<br>
Sounds like a similar optimisation to sys.intern() is for
strings.
<br>
<br>
I see no reason to try and avoid an import here - it's
definitely a special-case situation - but otherwise having a
function to say "clone and update this dict" that starts by
sharing the keys in the same way that __dict__ does (including
the transformation when necessary) seems like an okay addition.
Maybe copy() could just be enabled for this?
<br>
</blockquote>
<br>
Or possibly just "dict(existing_dict).update(new_items)".
<br>
<br>
My primary concern is still to avoid making CPython performance
characteristics part of the Python language definition. That only
makes it harder for alternate implementations. (Even though I was
out-voted last time on this issue since all the publicly-known
alternate implementations said it would be okay... I'm still going
to put in a vote for avoiding new language semantics for the sake
of a single runtime's performance characteristics.)<br>
</blockquote>
<br>
I note that dict() doesn't have a method to take two parallel
iterables of keys/values and create a dict... if it did, that could
be a trigger that a shared key dict might be appropriate... it seems
more likely that data in that form is dealing with rows and columns,
instead of the forms currently accepted by dict().<br>
<br>
Perhaps an alternate constructor that took data in that form, AND
defined an optional parameter to trigger a shared dict, would be a
useful addition to the language. Other implementations could ignore
the optional parameter if they want, and the implementation would be
a one-liner calling the current constructor and zip()ing the
parameters.<br>
<br>
The alternate constructor would be nice even if shared key dicts
were not particularly needed in an application, and would provide a
method of adding a trigger for the shared key optimization when
appropriate.<br>
</body>
</html>