On Thu, Feb 28, 2013 at 10:32 AM, Guido van Rossum <guido@python.org> wrote:
Hm. I write code regularly that takes a **kwargs dict and stores it into some other longer-lasting datastructure. Having that other datastructure suddenly receive OrderedDicts instead of plain dicts might definitely cause some confusion and possible performance issues.
Could you elaborate on what confusion it might cause? As to performance relative to dict, this has definitely been my primary concern. I agree that the impact has to be insignificant for the **kwargs proposal to go anywhere. Obviously OrderedDict in C had better be an improvement over the pure Python version or there isn't much point. However, it goes beyond that in the cases where we might replace current uses of dict with OrderedDict. My plan has been to do a bunch of performance comparison once the implementation is complete and tune it as much as possible with an eye toward the main potential internal use cases. From my point of view, those are **kwargs and class namespace. This is in part why I've brought those two up. For instance, one guidepost I've used is that typically **kwargs is going to be small. However, even for large kwargs I don't want any performance difference to be a problem.
And I don't recall ever having wanted to know the order of the kwargs in the call.
Though it may sound a little odd, the first use case I bumped into was with OrderedDict itself: OrderedDict(a=1, b=2, c=3) There were a few other reasonable use cases mentioned in other threads a while back. I'll dig them up if that would help.
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. -eric