On Sun, Jun 15, 2008 at 6:01 AM, Barry Warsaw <barry@python.org> wrote:
On Jun 15, 2008, at 1:43 AM, Raymond Hettinger wrote:
The second one is a bit weird because a key "loses its place" whenever the value is updated.
Heh, neither of these would work for the email package's own flavor of "ordered" dictionary. Its .items() will return all three key/val pairs, but it's __getitem__ interface would only return the first two, and there are additional interfaces exposed for .get_all() (which is like .get() but returns a list of values matching the given key).
Okay, so email couldn't use whatever stdlib odict gets added, but I think that just shows that this may not be as fundamental a data structure as we think it is. I'd much rather see a package on the cheeseshop gain overwhelming popularity, practically forcing us to include it in the stdlib.
+1 on this comment, -0 on adding an ordered dict to 2.6/3.0. An ordered (or sorted) dict seems to be more of a gut reaction. They have some data in a dict, they realize they want it ordered/sorted for some purpose, so the first thing they check is if the dict already provides it. It doesn't, but putting together a combination of a dict and a list is often a fair bit of work - nevermind if you want O(1) removal - so we hear about it in the mean time. But my point is that we we need to focus on finding real use cases and exploring how best to solve them. Otherwise we might as well throw in my OrderedSet[1] as-is, despite that it's got no comments and no ratings. Even I don't seem to use it. Everybody has an opinion on the colour of this bikeshed. [1] http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/528878 -- Adam Olsen, aka Rhamphoryncus