On Thu, Feb 28, 2013 at 2:28 PM, Guido van Rossum <guido@python.org> wrote:
What happens to the performance if I insert many thousands (or millions) of items to an OrderedDict? What happens to the space it uses? The thing is, what started out as OrderedDict stays one, but its lifetime may be long and the assumptions around dict performance are rather extreme (or we wouldn't be redoing the implementation regularly).
<snip/>
So, in my use case, the kwargs is small, but the object may live a long and productive life after the function call is only a faint memory, and it might grow dramatically.
Good point. My own use of **kwargs rarely sees the object leave the function or get very big, and this aspect of it just hadn't come up to broaden my point of view. I'm glad we're having this discussion. My intuition is that such a use case would be pretty rare, but even then...
IOW I have very high standards for backwards compatibility here.
...Python has an exceptional standard in this regard. FWIW, I agree. I would want to be confident about the ramifications before we made any change like this.
There were a few other reasonable use cases mentioned in other threads a while back. I'll dig them up if that would help.
It would.
Okay.
But even apart from that backwards incompatibility I think this feature is too rarely useful to make it the default behavior -- if anything I want **kwargs to become faster!
You mean something like possibly not unpacking the **kwargs in a call into another dict?
def f(**kwargs): return kwargs d = {'a': 1, 'b': 2} assert d is f(**d)
Certainly faster, though definitely a semantic difference.
No, that would introduce nasty aliasing problems in some cases. I've actually written code that depends on the copy being made here. (Yesterday, actually. :-)
You can't blame me for trying to make **kwargs-as-OrderedDict seem like a great idea in comparison. <wink> -eric