[Python-ideas] Ordering keyword dicts

Nick Coghlan ncoghlan at gmail.com
Mon Jun 10 08:07:41 CEST 2013


On 10 June 2013 15:46, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
>
> On Mon, Jun 10, 2013 at 1:14 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> The various "CALL_FUNCTION*" opcodes in CPython almost always end up
>> passing through a snippet like the following in ceval.c [1,2] (there
>> are a couple of exceptions related to optimisation of calls that only
>> involve positional arguments and parameters):
>>
>>     if (PyCFunction_Check(func)) {
>>         PyThreadState *tstate = PyThreadState_GET();
>>         C_TRACE(result, PyCFunction_Call(func, callargs, kwdict));
>>     }
>>     else
>>         result = PyObject_Call(func, callargs, kwdict);
>
> This is correct for calling functions implemented in C, but python function
> calls go through a special treatment:
>
>         if (PyFunction_Check(func))
>             x = fast_function(func, pp_stack, n, na, nk);
>
> Eventually, this gets to PyEval_EvalCodeEx, where keyword arguments are
> still ordered.  I believe this would be the place where a new co_* flag can
> be checked and order preserved.

There are *many* ways to invoke a Python function which won't go
through fast_function. Either there's a flag on callables for the
runtime to check to
see if order needs to be preserved, or else there needs to be an
explicit syntactic marker at the call site to indicate that order
should be preserved.

Whichever approach is being considered, the other problem with the
sometimes-ordered-sometimes-not issue is how to avoid having wrappers
implicitly discard the ordering, regardless of whether the request for
ordering is "outside in" (requested at the call site), "inside out"
(requested in the function definition) or both.

A new language could easily just define keyword arguments as ordered
and accept the resulting performance hit. Retrofitting ordered keyword
arguments to an existing language without substantially hurting
performance of an already slow operation, while still making the
feature usable enough to be attractive is a much harder problem. "Just
add an ordered dict literal instead" is tempting, but then nice
spellings for that start looking like they could be made more general
:)

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list