On 22Apr2019 1921, Steve Dower wrote: > On 22Apr2019 1822, Glenn Linderman wrote: >> 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. > > Sounds like a similar optimisation to sys.intern() is for strings. > > I see no reason to try and avoid an import here - it's definitely a > special-case situation - but otherwise having a function to say "clone > and update this dict" that starts by sharing the keys in the same way > that __dict__ does (including the transformation when necessary) seems > like an okay addition. Maybe copy() could just be enabled for this? Or possibly just "dict(existing_dict).update(new_items)". My primary concern is still to avoid making CPython performance characteristics part of the Python language definition. That only makes it harder for alternate implementations. (Even though I was out-voted last time on this issue since all the publicly-known alternate implementations said it would be okay... I'm still going to put in a vote for avoiding new language semantics for the sake of a single runtime's performance characteristics.) 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