On Tue, May 14, 2013 at 7:34 PM, Steven D'Aprano firstname.lastname@example.org wrote:
On Tue, May 14, 2013 at 12:53:53PM -0700, Jonathan Eunice wrote:
But from an app developer’s point of view, ordering is a basic, essential property.
Speak for yourself. I don't think it is, and while having a fixed order is sometimes useful, often it is not necessary.
The fact that it is often useful -- if only for debugging and testing -- can make it seem like a basic property that shouldn't be sacrificed without a reason.
Think of the contortions that dict code (prior to the Denial Of Service scare) went through to maintain a stable (albeit arbitrary) order.
I also suspect I'm not the only one who looks at the self.(var) = (var) of an __init__ function and feels that the arguments are really more of an association-list, so that creating a map was just wasted work. I do NOT propose to fix this code smell in the general case, though.
Frankly, with the exception of OrderedDict itself, if your functions would like to treat kwargs args differently based on their order, e.g. func(a=1, b=2) vs func(b=2, a=1), I think your design may be broken.
I agree. But the line between "broken" and "easier to debug" isn't always bright. (That said, if kwargs in particular were essentially ordered, I would want to allow repeats, as do the web mappings. I'm not sure that would be a net positive for readability.)
Historically, sort features were usually unstable because that’s easier to implement
Not really, for the more obvious algorithms. But those aren't the fastest.
and faster to run. Over time, stable sort has become the norm,
Stable sorting is intuitively correct.
My intuition is that if two objects are equal, it shouldn't matter what order they come in. Preference for a stable sort only comes after lots of experience with data flows involving (or abusing) multi-step sorts.