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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4