On 23Apr2019 0034, Glenn Linderman wrote:
On 4/22/2019 10:59 PM, Steve Dower wrote:
On 22Apr2019 2119, Glenn Linderman wrote:
While Inada's suggested DictBuilder interface was immediately
obvious, I don't get how either copy or update would achieve the
goal. Perhaps you could explain? Particularly, what would be the
trigger that would make dict() choose to create a shared key
dictionary from the start? Unless it is known that there will be lots
of (mostly static) dictionaries with the same set of keys at the time
of creation of the first one, creating a shared key dictionary in
every case would cause later inefficiencies in converting them, when
additional items are added? (I'm assuming without knowledge that a
single shared key dictionary is less efficient than a single regular
dictionary.)
Passing a dictionary to the dict() constructor creates a copy of that
dictionary (as does copy.copy()). What other trigger do you need to
decide "it contains the same keys"? It's a copy of the original dict,
so by definition at that point it may as well share its entire
contents with the original.
But if the original dictionary wasn't created with shared keys... the
copy can't share them either. Or are you suggesting adding new code to
create a shared key dictionary from one that isn't?
This is a good point. Maybe dict.fromkeys() could do it? Or a
sys.intern-like function (which is why I brought up that precedent). The
point is to make it an optional benefit rather than strict
language/library semantics.
Is there a cost to using a key sharing dict that is prohibitive when the
keys aren't actually being shared?
Cheers,
Steve
_______________________________________________
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
