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? > > Basically this is just a partial copy-on-write, where we copy values > eagerly - since they're almost certainly going to change - and keys > lazily - since there are known scenarios where they are not going to > be changed, but we'll pay the cost later if it turns out they are. > > Cheers, > Steve > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20190423/39ab4652/attachment-0001.html>
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