On Tue, May 14, 2013 at 5:23 PM, Andrew Barnert <abarnert@yahoo.com> wrote:

On May 14, 2013, at 12:53, Jonathan Eunice <jonathan.eunice@gmail.com> wrote:
Using a compatible, separate implementation for OrderedDict is a fine way to gracefully extend the language, but it leaves ordering only half-accomodated. Consider:
OrderedDict(a=2, b=3, c=7)
If your proposal is to replace dict with OrderedDict, I think you need at least one use case besides OrderedDict's constructor.

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).

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:

def create_element(tag, text='', **attributes):
    attrs = ['{}="{}"'.format(k,v) for k, v in attributes.items()]
    return "<{0} {1}>{2}</{0}>".format(tag, ' '.join(attrs), text)

print(create_element('img', alt="Some cool stuff.", src="coolstuff.jpg"))
<img src="coolstuff.jpg" alt="Some cool stuff."></img>

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:

>>> create_element('img', [('alt', 'Some cool stuff.'), ('src', 'coolstuff.jpg')])

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. ;-)