[Python-ideas] `OrderedDict.sort`

[Nick Coghlan]

On 25 Sep 2013 01:52, "Ram Rachum" <ram at rachum.com> wrote:
>
> I get your point. It's a nice idea. But I think it's slightly less
elegant to create another dict. So I think it's almost as good as having a
`.sort` method, but not quite as nice.
>
> (By the way, couldn't you make the same argument about `list.sort`?)

No, because list.sort() both predates the sorted builtin and is optimised
to be blazingly fast with reasonable memory overhead by directly
interacting with internal details of the list object. It's actually the
pre-existing list sorting machinery that powers the builtin.

The situation is different now: the sorted builtin provides a generic API
to get a sorted version of any iterable. This means a proposed in-place
sort() method on a container has to demonstrate a few things to overcome
the "default deny" that is applied to any proposal to add more methods to
an object interface:

- there are common use cases that can't be handled by sorting the input
when creating the container in the first place
- there are significant speed gains from an in-place sorting operation
- there are significant memory gains from an in-place sorting operation

Now, in the case of OrderedDict it *may* be possible to back up one or more
of those assertions (especially the latter two if you talk to Eric Snow
about an in-place sort method for his C implementation of the API).

However, in the absence of such evidence, the default reaction will always
be to avoid expanding APIs with functionality that can be provided by
applying external algorithms to the existing API.

Cheers,
Nick.



>
>
> On Tue, Sep 24, 2013 at 6:49 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>>
>> On 24.09.2013 17:23, Ram Rachum wrote:
>> > Ethan, you've misunderstood my message and given a correct objection
to an
>> > argument I did not make.
>> >
>> > I did not argue against ordering by insertion order on init. I agree
with
>> > that decision. I disagree with defining the entire class as an
insertion
>> > ordering class and refusing to allow users to reorder it as they wish
after
>> > it's created.
>>
>> The overhead introduced by completely recreating the internal
>> data structure after the sort is just as high as creating a
>> new OrderedDict, so I don't understand why you don't like about:
>>
>> from collections import OrderedDict
>> o = OrderedDict(((3,4), (5,4), (1,2)))
>> p = OrderedDict(sorted(o.iteritems()))
>>
>> This even allows you to keep the original insert order should
>> you need it again. If you don't need this, you can just use:
>>
>> o = dict(((3,4), (5,4), (1,2)))
>> p = OrderedDict(sorted(o.iteritems()))
>>
>> which is also faster than first creating an OrderedDict and
>> then recreating it with sorted entries.
>>
>> Put those two lines into a function and you have:
>>
>> def SortedOrderedDict(*args, **kws):
>>     o = dict(*args, **kws)
>>     return OrderedDict(sorted(o.iteritems()))
>>
>> p = SortedOrderedDict(((3,4), (5,4), (1,2)))
>>
>> --
>> Marc-Andre Lemburg
>> eGenix.com
>>
>> Professional Python Services directly from the Source  (#1, Sep 24 2013)
>> >>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>> >>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>> >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
>> ________________________________________________________________________
>> 2013-09-11: Released eGenix PyRun 1.3.0 ...       http://egenix.com/go49
>> 2013-09-28: PyDDF Sprint ...                                4 days to go
>> 2013-10-14: PyCon DE 2013, Cologne, Germany ...            20 days to go
>>
>>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>>            Registered at Amtsgericht Duesseldorf: HRB 46611
>>                http://www.egenix.com/company/contact/
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130925/a54419e8/attachment-0001.html>