On Tue, May 14, 2013 at 5:23 PM, Andrew Barnert
On May 14, 2013, at 12:53, Jonathan Eunice
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. ;-)