[Python-ideas] Preserving **kwargs order

[Nick Coghlan]

On 6 Apr 2014 05:12, "Eric Snow" <ericsnowcurrently at gmail.com> wrote:
>
> On Apr 4, 2014 10:04 AM, "David Mertz" <mertz at gnosis.cx> wrote:
> > I confess that after reading this thread, and a number of related past
ones, I'm still not certain exactly what problem all of this is needed to
solve.
>
> Yeah, it won't be worth it without justification.  :)  I'll spell it out
in the PEP, but basically it boils down to these reasons:
>
> * Helpful in debugging (from Raymond and others).
> * Controlling object presentation.
> * Anywhere you want to set iteration order and name/value in a single
call (from Nick).
>   + Factories for ordered types.
>   + Serializable objects where order matters.

In the context of serialisation, one key lesson we have learned is that
arbitrary ordering is a problem when you want to minimise spurious diffs,
and sorting isn't a simple solution.

Tools like doctest don't tolerate spurious diffs at all, but are often
amenable to a sorting based answer.

The cases where it would be highly desirable to be able use keyword
arguments to control the order of display of a collection of key value
pairs are ones like:

* printing out key:value pairs in CLI output
* mapping semantic names to column order in a CSV
* serialising attributes and elements in particular orders in XML
* serialising map keys in particular orders in human readable formats like
JSON and YAML (particularly when they're going to be placed under source
control)

These *can* all be done today, but *not* by using keyword arguments. In my
view, the problem to be addressed is that keyword arguments *look* like
they should work for these cases, because they have a definite order in the
source code. The only reason they don't work is because the interpreter
throws that ordering information away.

It's a textbook case of a language feature becoming an attractive nuisance
in some circumstances: the simple and obvious solution for the above use
cases *doesn't actually work* for reasons that aren't obviously clear if
you don't have a firm grasp of Python's admittedly complicated argument
handling.

The simplest way out that I can see? Just make it work, even if that means
also preserving the order of arbitrary keyword arguments in cases that
*dont* need it.

Deciding whether or not to provide a way to opt in to dropping the order
info for speed and memory reasons then becomes a separate optimisation
discussion *after* the current usability trap has been addressed.

Cheers,
Nick.

> * Keyword argument priority.
>
> I have a few more less concrete use cases as well.  OrderedDict is the
first example everyone cites, but it's simply the most obvious.
Furthermore, it's a rather self-referential example. :)  As I said, I'll
make the full case in the PEP, which I hope to get out today.
>
> > ISTM that if one has a special function calling requirement to pass in
an ordered collection of key/value pairs, one can already just use a
special and available call signature for your function:
> >
> >   def myfunc(a, b, *keyvals):
> >       od = OrderedDict(keyvals)
> >       # ... do other stuff
> >
> > Call this like:
> >
> >   value = myfunc(foo, bar, ('a',1), ('z',2), ('b',3))
> >
> > Yes, it's a slightly special form of the calling convention, but it
does something slightly special with its key/val-like arguments, so that
seems like a reasonable tradeoff.  The solution is purely local to the
writer of the function who needs this.
>
> That's clever.  However, it is basically the same as the status quo: if
you want to preserve order you cannot use keyword arguments, including **
unpacking, even though they are the natural way to do it.  For existing
functions, preserving order means changing code even though the order is
already available.  The point of my proposal is to teach the interpreter to
preserve the order.
>
> -eric
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140406/7ae38a50/attachment.html>