[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Proposal: dict.with_values(iterable)

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.)