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.