Re: [Python-ideas] OrderedDict.insert()

I withdraw the idea. Thank you all for your answers. Am 26.03.2015 um 11:08 schrieb Andrew Barnert:

On Mar 26, 2015, at 01:59, Thomas Güttler 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 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/