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

[Glenn Linderman]

On 4/22/2019 5:19 PM, Steven D'Aprano wrote:
> Oh, you mean just like regular dicts with shared keys already do:-)
>
> https://www.python.org/dev/peps/pep-0412/
>
> Perhaps I've missed something in this discussion, but isn't this a
> matter of just making the existing shared-keys functionality explicitly
> usable rather than just purely implicit? Quoting from the PEP:
>
>    When dictionaries are created to fill the __dict__ slot of an object,
>    they are created in split form. The keys table is cached in the type,
>    potentially allowing all attribute dictionaries of instances of one
>    class to share keys. In the event of the keys of these dictionaries
>    starting to diverge, individual dictionaries will lazily convert to
>    the combined-table form.
>
> There's no explicit interface to control this; it all happens by magic,
> behind the scenes. I think the proposal here is to add some sort of
> interface, possibly a new method, to explicitly use key sharing.

Thanks for the PEP reference; I'd forgotten some of the details, and 
hadn't yet gone to look them up.

Yes, it is all magic, but is only available for object __dict__ slot 
dicts. I'd forgotten that that was the "detection" mechanism.  In the 
general case, it would be too time-consuming to examine all existing 
dicts to discover some that might accidentally have the same keys, 
whereas Mark realized that objects very frequently have __dict__ slot 
dictionaries with the same keys, and were ripe for (significant memory 
and minor performance) optimization.

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.

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.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190422/ca34d53f/attachment-0001.html>