<p style="color: rgb(0, 0, 0); font-family: lato, sans-serif; line-height: 20px; "><span style="font-size: small; ">Python’s nicely evolved its standard data structures. Bringing</span><span style="font-size: small; "> </span><code style="color: rgb(0, 0, 102); padding-right: 2px; padding-left: 2px; ">set</code><span style="font-size: small; "> </span><span style="font-size: small; ">into the core, adding </span><code style="color: rgb(0, 0, 102); padding-right: 2px; padding-left: 2px; ">OrderedDict</code><span style="font-size: small; "> </span><span style="font-size: small; ">(and friends), and establishing collections ABCs—all these up-level common facilities, broadly improving program clarity and correctness.</span><br></p><p style="color: rgb(0, 0, 0); font-family: lato, sans-serif; line-height: 20px; "><font size="2">I’d like Python to take the next step, especially regarding ordering.</font></p><p style="color: rgb(0, 0, 0); font-family: lato, sans-serif; line-height: 20px; "><font size="2">Using a compatible, separate implementation for <code style="color: rgb(0, 0, 102); padding-right: 2px; padding-left: 2px; ">OrderedDict</code> is a fine way to gracefully extend the language, but it leaves ordering only half-accomodated. Consider:</font></p><div class="codehilite" style="margin: 0.25in; color: rgb(0, 0, 0); font-family: lato, sans-serif; line-height: 20px; "><pre><font size="2"><span class="n">OrderedDict</span><span class="p">(</span><span class="n">a</span><span class="o" style="color: rgb(102, 102, 102); ">=</span><span class="mi" style="color: rgb(64, 160, 112); ">2</span><span class="p">,</span> <span class="n">b</span><span class="o" style="color: rgb(102, 102, 102); ">=</span><span class="mi" style="color: rgb(64, 160, 112); ">3</span><span class="p">,</span> <span class="n">c</span><span class="o" style="color: rgb(102, 102, 102); ">=</span><span class="mi" style="color: rgb(64, 160, 112); ">7</span><span class="p">)</span>
</font></pre></div><p style="color: rgb(0, 0, 0); font-family: lato, sans-serif; line-height: 20px; "><font size="2">yields:</font></p><div class="codehilite" style="margin: 0.25in; color: rgb(0, 0, 0); font-family: lato, sans-serif; line-height: 20px; "><pre><font size="2"><span class="n">OrderedDict</span><span class="p">([(</span><span class="sc" style="color: rgb(64, 112, 160); ">'a'</span><span class="p">,</span> <span class="mi" style="color: rgb(64, 160, 112); ">2</span><span class="p">),</span> <span class="p">(</span><span class="sc" style="color: rgb(64, 112, 160); ">'c'</span><span class="p">,</span> <span class="mi" style="color: rgb(64, 160, 112); ">7</span><span class="p">),</span> <span class="p">(</span><span class="sc" style="color: rgb(64, 112, 160); ">'b'</span><span class="p">,</span> <span class="mi" style="color: rgb(64, 160, 112); ">3</span><span class="p">)])</span>
</font></pre></div><p style="color: rgb(0, 0, 0); font-family: lato, sans-serif; line-height: 20px; "><font size="2">The items are immediately disordered, having been jumbled passing through a conventional <code style="color: rgb(0, 0, 102); padding-right: 2px; padding-left: 2px; ">dict</code>. One can initialize using a list of items, of course, but that reminds me of the line from NetHack: “You enter what seems to be an older, more primitive world.”</font></p><p style="color: rgb(0, 0, 0); font-family: lato, sans-serif; line-height: 20px; "><font size="2">Everyone rightly accepts doing a bit more specification for truly “extra” data structure features—persistence, say. And if falling back to lists of tuples is the best that can be done for ordered structures, well, okay. We’ll live with it.</font></p><p style="color: rgb(0, 0, 0); font-family: lato, sans-serif; line-height: 20px; "><font size="2">But from an app developer’s point of view, ordering is a basic, essential property. It seems like something that should be gracefully accommodated, as a built-in, rather than as “an extra” or something that requires falling back to Late Medieval Python. kwargs arrived in 1.4, back in 1996, right?</font></p><p style="color: rgb(0, 0, 0); font-family: lato, sans-serif; line-height: 20px; "><font size="2">So I propose that kwargs, at least, default to an ordered mapping rather than a pure hash mapping. Ideally, <code style="color: rgb(0, 0, 102); padding-right: 2px; padding-left: 2px; ">{...}</code>  literals would also be ordered. I suspect this will be an unpopular idea among implementers, for whom unordered <code style="color: rgb(0, 0, 102); padding-right: 2px; padding-left: 2px; ">dict</code> is a pervasive and long-optimized tool. But this is a correctness, or at least a consistency, issue. I don’t see any elegant alternative way to initialize ordered data structures unless the modern Python initialization idiom(s), esp. kwargs, themselves observe order.</font></p><p style="color: rgb(0, 0, 0); font-family: lato, sans-serif; line-height: 20px; "><font size="2">Historically, sort features were usually unstable because that’s easier to implement and faster to run. Over time, stable sort has become the norm, either as an option (e.g. GNU’s <code style="color: rgb(0, 0, 102); padding-right: 2px; padding-left: 2px; ">sort --stable</code>, Perl’s <code style="color: rgb(0, 0, 102); padding-right: 2px; padding-left: 2px; ">use sort 'stable'</code> as of 5.8) or implicitly (e.g. Python’s <code style="color: rgb(0, 0, 102); padding-right: 2px; padding-left: 2px; ">sorted</code>, as of 2.2). Over time, getting better results proved more broadly important than getting near-correct results faster; and both by code optimization and system improvement, the associated time or space cost of stable ordering was mooted. I’d like the same to happen for Python mappings. It’s my understanding that Ruby 1.9 has recently made this shift.</font></p>