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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
