[Python-ideas] OrderedDict for kwargs and class statement namespace
Eric Snow
ericsnowcurrently at gmail.com
Thu Feb 28 23:18:08 CET 2013
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
More information about the Python-ideas
mailing list