On 4/22/2019 7:27 PM, Steve Dower wrote:
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.)
I note that dict() doesn't have a method to take two parallel iterables
of keys/values and create a dict... if it did, that could be a trigger
that a shared key dict might be appropriate... it seems more likely that
data in that form is dealing with rows and columns, instead of the forms
currently accepted by dict().
Perhaps an alternate constructor that took data in that form, AND
defined an optional parameter to trigger a shared dict, would be a
useful addition to the language. Other implementations could ignore the
optional parameter if they want, and the implementation would be a
one-liner calling the current constructor and zip()ing the parameters.
The alternate constructor would be nice even if shared key dicts were
not particularly needed in an application, and would provide a method of
adding a trigger for the shared key optimization when appropriate.
_______________________________________________
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
