On 6 Apr 2014 05:12, "Eric Snow"
On Apr 4, 2014 10:04 AM, "David Mertz"
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.
* 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
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. preserve the order.
-eric
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/