[Python-ideas] Let's be more orderly!

[Jim Jewett]

On Tue, May 14, 2013 at 7:34 PM, Steven D'Aprano <steve at pearwood.info> 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.

-jJ