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