On 05/14/2013 07:38 PM, Daniel Holth wrote:
On Tue, May 14, 2013 at 10:07 PM, Ethan Furman
wrote: On 05/14/2013 06:57 PM, Don Spaulding wrote:
On Tue, May 14, 2013 at 5:23 PM, Andrew Barnert
mailto:abarnert@yahoo.com> wrote: On May 14, 2013, at 12:53, Jonathan Eunice
mailto: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's not being dismissed, but it's only one. There are thousands of functions using **kwds that simply don't care about the order. Should they all pay the performance price so that some tiny fraction can benefit?
While it is correctly said that if performance is a Big Deal you shouldn't be using Python, we also are not interested in making it slower without a really good reason.
I'm not convinced that the performance argument is valid. There are clever ways to optimize ordered dicts. It would be quite a change to the language.
Best way to find out is branch and try it. Then we'll have hard numbers instead of lots of hand waving and opinions. ;) If any performance hit is negligible I would certainly be interested in having them. -- ~Ethan~