Eric Snow added the comment: > I'm going to echo the previous comment that maybe trying to emulate the > existing dict implementation too carefully just adds complexity.
The whole dance with _odict_get_index and _odict_resize is due to the requirement that OrderedDict maintain O(1) operation for deletion operations. Due to using a linked list, we needed a secondary mechanism for efficiently indexing into the list. There is a note at the top of the file explaining the alternatives I considered and the rationale for mirroring dict's hash table. > > The split-keys implementation shows that there is at least some flexibility > to the implementation. Enough that the keys could map to an array offset, > rather than directly to the values? What do you mean by this? If you are suggesting changes to dict or its accessory types then it is something I considered and rejected. Personally I don't want to change anything on dict itself for the sake of OrderedDict. If others would like to pursue that they're welcome to do so. :) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16991> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
