<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 14, 2013 at 5:23 PM, Andrew Barnert <span dir="ltr"><<a href="mailto:abarnert@yahoo.com" target="_blank">abarnert@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div>On May 14, 2013, at 12:53, Jonathan Eunice <<a href="mailto:jonathan.eunice@gmail.com" target="_blank">jonathan.eunice@gmail.com</a>> wrote:</div>
<div><br></div><blockquote type="cite"><p style="line-height:20px;font-family:lato,sans-serif"><span style="font-size:small">Using a compatible, separate implementation for </span><code style="font-size:small;color:rgb(0,0,102);padding-right:2px;padding-left:2px">OrderedDict</code><span style="font-size:small"> is a fine way to gracefully extend the language, but it leaves ordering only half-accomodated. Consider:</span></p>
<div style="line-height:20px;font-family:lato,sans-serif;margin:0.25in"><pre><font><span>OrderedDict</span><span>(</span><span>a</span><span style="color:rgb(102,102,102)">=</span><span style="color:rgb(64,160,112)">2</span><span>,</span> <span>b</span><span style="color:rgb(102,102,102)">=</span><span style="color:rgb(64,160,112)">3</span><span>,</span> <span>c</span><span style="color:rgb(102,102,102)">=</span><span style="color:rgb(64,160,112)">7</span><span>)</span>
</font></pre></div><p style="line-height:20px;font-family:lato,sans-serif"></p></blockquote></div><div>If your proposal is to replace dict with OrderedDict, I think you need at least one use case besides OrderedDict's constructor.</div>
</div></blockquote><div><br></div><div>I don't understand the dismissal of OrderedDict.__init__ as an invalid use case. It would be a substantial usability improvement to special-case OrderedDict at compile-time purely to get the ability to instantiate odict literals (not that I'm suggesting that).<br>
<br>In the interest of moving the discussion forward, I've had a few use cases along these lines. Let's say I want to create simple HTML elements by hand:<br><br></div><span style="font-family:courier new,monospace"> def create_element(tag, text='', **attributes):<br>
attrs = ['{}="{}"'.format(k,v) for k, v in attributes.items()]<br>
return "<{0} {1}>{2}</{0}>".format(tag, ' '.join(attrs), text)<br> <br> print(create_element('img', alt="Some cool stuff.", src="coolstuff.jpg"))<br>
<img src="coolstuff.jpg" alt="Some cool stuff."></img></span><br><br></div>In python today, if I want to the attributes to retain the order in which they appear as arguments, the function has to be changed in such a way that all calling code is forced to look like some variation on this theme:<br>
<br></div><div class="gmail_extra"><span style="font-family:courier new,monospace"> >>> create_element('img', [('alt', 'Some cool stuff.'), ('src', 'coolstuff.jpg')])</span><br>
<br></div><div class="gmail_extra">It's not that it's impossible to do, it's that dict-based API's would benefit from the function being able to decide on its own whether or not it cared about the order of arguments. Having to express a kwargs-based or plain-old-dict-based function as a list-of-2-tuples function is... uncool. ;-)<br>
</div></div>