On 03/25/2015 12:51 PM, Andrew Barnert wrote:

On Mar 25, 2015, at 04:00, Thomas Güttler<guettliml@thomas-guettler.de> wrote:

...

...

I am missing OrderedDict.insert()

With what interface? Does it take an index, like list.insert, even though other OrderedDict methods (including __getitem__ and friends) don't? Or does it take another key? If so, does it insert before or after that key? And what if that key doesn't exist? Meanwhile, if the new key was already in the dict, should it move to the new position, update values in place, or raise an exception? Do you expect O(1) performance?

...

...

Other people, too:

...

...

http://stackoverflow.com/questions/16664874/how-can-i-add-the-element-at-the...

That other person is asking for some way to put a new element on the left instead of the right, which doesn't have any of those issues. (And which is already possible with move_to_end.) And an anonymous low-rep user asking a question, getting a handful of upvotes, and accepting an answer that says "You can't, just build a new dict" with no comment doesn't exactly show a burning desire within a wide community.

In fact, I think this does a better job showing how OrderedDict is often an attractive nuisance than how it's incomplete--the guy can't explain why he wants this, and meanwhile he apparently thinks you have to build a new dict and call update to add a value (or at least that doing so should have a different result than just using __setitem__ with that new key and value). My guess is that either he didn't really want an OrderedDict in the first place, or Zagorulkin Dmitri is right that the real problem is that his program needs this feature and it should be rewritten so it doesn't. But without actually knowing the use case that's just a guess.

As to OrderedDict being a an attractive nuisance, I'm not sure. I do think there are data structures that benefit from being index-able by both position and by name. Scheme uses association lists for this, and documents that they are a bit slower than mappings. But it is easy to convert one to the other and back again. In python you can convert to a list of items and back. But it can be expensive to keep two versions of the same data in memory or to constantly convert back and forth. An ordered dict insures the conversion to an items list will result in a dependable order. That may be the primary benefit. One way to do an insert is to mirror how the __init__ method works with items, but with an index for the first value. Dict.insert_items(index, items) Another possibility is to have both get_items and set_items methods than accept an index or slice object as the first argument. The __getitem__ and __setitem__ methods should not take an index in a dictionary. It is a dictionary first, and ordered data second. If it was an association list, then this would be reversed. Cheers, Ron

On Mar 26, 2015, at 01:59, Thomas Güttler <guettliml@thomas-guettler.de> wrote:

...

Am 25.03.2015 um 20:59 schrieb Ron Adam:

...

On 03/25/2015 12:51 PM, Andrew Barnert wrote: On Mar 25, 2015, at 04:00, Thomas Güttler<guettliml@thomas-guettler.de> wrote:

...

...

...

I am missing OrderedDict.insert()

...

With what interface? Does it take an index, like list.insert, even though other OrderedDict methods (including __getitem__ and friends) don't? Or does it take another key? If so, does it insert before or after that key? And what if that key doesn't exist? Meanwhile, if the new key was already in the dict, should it move to the new position, update values in place, or raise an exception? Do you expect O(1) performance?

My use case is that django drops support for SortedDict, and you should use collection.OrderedDict in the future:

https://code.djangoproject.com/wiki/SortedDict

From a quick scan (see https://github.com/django/django/commit/7379d9aceab01e007966b5fe1f47ba7590de...), it looks like Django deprecated insert in 1.5--two versions before deprecating SortedDict itself, while the type was still being heavily used all over Django itself. That implies that they didn't think it belonged there either (although I didn't find the issue or discussion where they made that decision, so don't take that as gospel--for all I know maybe they just discovered a bad bug in their implementation and decided deprecating it would break less code than changing it...). Meanwhile, that's not really a use case. Without any idea of why you used SortedDict.insert, I still have no clue why someone would use OrderedDict.insert. I don't think it's worth adding stuff to Python's stdlib just to make it easier for people porting pre-Django-1.5 code to Django 1.9 to work around an intentional change in Django.

We have one line where we use my_ordered_dict.insert() and this line is already updated. The issue is not very important for me.

To your question:

The interface of django was insert(index, key, value) but you are right. An interface which is relative to an existing key would be better.

I'm not sure about that. I suspect inserting at the front would be one of the more common uses for this (again, just guessing, because I don't know of _any_ real-life uses... but that was what the SO question you linked to wanted...), which would be pretty clumsy with before-key instead of before-index. But that was part of the point. I don't think the meaning or interface of OrderedDict.insert is obvious, and you didn't say what you wanted it to do. In fact what you really wanted and what Django used to do are different, so what are the odds that whichever one we chose, some users would have guessed the opposite?

insert_before(other_key, new_key, new_value)

insert_behind(other_key, new_key, new_value)

Both methods should raise KeyError if other_key is not in the dict and should raise KeyError if new_key is already in the dict.

Performance: I don't care. I store big data in a database. I don't carry it around in the memory if the python interpreter.

Regards, Thomas Güttler _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/