On Thu, Feb 28, 2013 at 2:32 PM, Alex Stewart <foogod@gmail.com> wrote:
such that all future implementations of dict (and all implementations in any Python, not just CPython) must be guaranteed to also behave this way?
This is also a good point applied to both **kwargs and class namespace. Before we did either we'd need to be clear on the impact on other Python implementors.
However, for function calls, which I actually believe is the more important question, I think we would have to think very hard about anything that introduced any real performance overhead, because functions are typically called a _lot_. Adding even a small extra delay to function calls could impact the overall performance of some types of Python programs substantially..
**kwargs-as-OrderedDict impacts performance in two ways: the performance of packing the "unbound" keyword arguments into the OrderedDict and the performance of OrderedDict in normal operation after its handed off to the function. Otherwise you don't get a performance impact on functions.
I also agree with Guido that there may be some unexpected consequences of suddenly changing the type of the kwargs parameter passed to functions which were coded assuming it would always be a plain-ol' dict.. I think it might be doable, but we'd have to be very sure that OrderedDict is exactly compatible in every conceivable way..
For Python backward compatibility is a cornerstone. I'm surprised there isn't something in the Zen about it. <wink> For **kwargs the bar for compatibility is especially high and I agree with that.
Perhaps instead we could compromise by keeping the default case as it is, but providing some mechanism for the function declaration to specify that it wants ordering information passed to it? I'm not sure what a good syntax for this would be, though ("(*args, ***okwargs)"? "(*args, **kwargs, *kworder)"? Not sure I'm really big on either of those, actually, but you get the idea..)
**kwargs packing happens in the interpreter rather than in relationship to functionality provided by the function, so whatever the mechanism it would have be something the interpreter consumes, either a new API/syntax for building functions or a new syntax like you've mentioned. This has come up before. Classes have metaclasses (and __prepare__). Modules have loaders. Poor, poor functions. Because of the same concerns you've already expressed regarding the criticality of function performance, they miss out on all sorts of fun--inside their highly optimized box looking out at the other types showing off their cool new features all the time. It just isn't fair. :) -eric