[issue19414] OrderedDict.values() behavior for modified instance

Serhiy Storchaka added the comment: See also issue19332. -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailin

[issue19414] OrderedDict.values() behavior for modified instance

Ethan Furman added the comment: Personally, I would rather see a RuntimeError raised. -- ___ Python tracker ___ ___ Python-bugs-list m

[issue19414] OrderedDict.values() behavior for modified instance

Nikolaus Rath added the comment: Hmm. I see your point. You might be right (I'm not fully convinced yet though), but this bug is probably not a good place to go into more detail about this. So what would be the best way to fix the immediate problem this was originally about? Raise a RuntimeErr

[issue19414] OrderedDict.values() behavior for modified instance

Ethan Furman added the comment: Nikolaus, in reply to your question about "more to remember": Even though I may not use it myself, if it is allowed then at some point I will see it in code; when that happens the sequence of events is something like: 1) hey, that won't work 2) oh, wait, is

[issue19414] OrderedDict.values() behavior for modified instance

Ethan Furman added the comment: Firstly, you're not copying the entire dict, just its keys. [1] Secondly, you're only copying the keys when you'll be adding/deleting keys from the dict. Thirdly, using the list idiom means you can use OrderedDicts, defaultdicts, dicts, sets, and most likely an

[issue19414] OrderedDict.values() behavior for modified instance

Nikolaus Rath added the comment: Ethan: when you say "..the more there is to remember", what exactly do you mean? I can see that it is important to remember that you're *not allowed* to make changes during iteration for a regular dict. But is there really a significant cognitive burden if it w

[issue19414] OrderedDict.values() behavior for modified instance

Nikolaus Rath added the comment: The workaround is trivial, but there is no technical necessity for it, and it involves copying the entire dict into a list purely for.. what exactly? I guess I do not understand the drawback of allowing changes. What is wrong with for key in ordered_dict:

[issue19414] OrderedDict.values() behavior for modified instance

Ethan Furman added the comment: The further from dict it goes, the more there is to remember. Considering the work around is so simple, I just don't think it's worth it: for key in list(ordered_dict): if some_condition: del ordered_dict[key] A simple list around the di

[issue19414] OrderedDict.values() behavior for modified instance

Nikolaus Rath added the comment: I agree that OrderedDict is more a dict than a list, but it is not clear to me why this means that it cannot extend a dict's functionality in that respect. OrderedDict already adds functionality to dict (preserving the order), so why shouldn't it also allow cha

[issue19414] OrderedDict.values() behavior for modified instance

Ethan Furman added the comment: Ah, right you are: list just acts wierd. ;) So the question then becomes is OrderedDict more like a list or more like a dict? It seems to me that OrderedDict is more like a dict. -- ___ Python tracker

[issue19414] OrderedDict.values() behavior for modified instance

Armin Rigo added the comment: 'list' doesn't, precisely. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue19414] OrderedDict.values() behavior for modified instance

Ethan Furman added the comment: Do we currently have any data structures in Python, either built-in or in the stdlib, that aren't documented as raising RuntimeError if the size changes during iteration? list, dict, set, and defaultdict all behave this way. If not, I think OrderedDict should b

[issue19414] OrderedDict.values() behavior for modified instance

Armin Rigo added the comment: Hi Raymond! Yes, I had the same reaction at first, but then it seemed to be possible to implement a reasonably good behavior with almost no performance hit. Plainly undefined behaviors are a mess for other implementations because in half of the big projects peopl

[issue19414] OrderedDict.values() behavior for modified instance

Raymond Hettinger added the comment: I'm inclined to document that "iterating views while adding or deleting entries an ordered dictionary is an undefined behavior". -- ___ Python tracker _

[issue19414] OrderedDict.values() behavior for modified instance

Changes by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue19414] OrderedDict.values() behavior for modified instance

Nikolaus Rath added the comment: I'd be happy to provide a more extensive patch along the lines Armin suggested if that is considered a good idea (not sure who has to make that decision). -- ___ Python tracker ___

[issue19414] OrderedDict.values() behavior for modified instance

Armin Rigo added the comment: Modifying an ordered dict while iterating over it can be officially classified as an ok think to do, but then the precise behavior must described in the documentation in some details, with of course matching implementation(s) and tests. I mean by that that the be

[issue19414] OrderedDict.values() behavior for modified instance

Nikolaus Rath added the comment: Being able to modify an OrderedDict while iterating through it is pretty useful though. What about documenting that modifying an OrderedDict is allowed, but may cause iteration to skip or repeat items (but do not allow it to raise RuntimeError)? As far as I ca

[issue19414] OrderedDict.values() behavior for modified instance

Armin Rigo added the comment: Another option for the "try harder to raise RuntimeError" category (which I tend to like, because otherwise people are bound to write programs that rely on undocumented details): In __delitem__() set link.next = None. In the various iterators check explicitly if

[issue19414] OrderedDict.values() behavior for modified instance

Changes by Ned Deily : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue19414] OrderedDict.values() behavior for modified instance

Nikolaus Rath added the comment: After thinking about this a bit more, I think this is actually a true bug in OrderedDict(), and only option (a) or be (b) really fix it. Rationale: I would expect that for any OrderedDict d, and any function modify_dict(d), the following assertion holds: for

[issue19414] OrderedDict.values() behavior for modified instance

New submission from Nikolaus Rath: The documentation says the following about modifying a dict while iterating through its view: | Iterating views while adding or deleting entries in the dictionary may | raise a RuntimeError or fail to iterate over all entries. (http://docs.python.org/3/library/