[Python-ideas] OrderedDict for kwargs and class statement namespace

[Eric Snow]

On Thu, Feb 28, 2013 at 2:32 PM, Alex Stewart <foogod at 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