>> I think it would be probably the best to hide the keys list from the >> public, but to provide list methods for reordering them (sorting, >> slicing etc.).
Tom Anderson wrote: > I'm not too keen on this - there is conceptually a list here, even if > it's one with unusual constraints, so there should be a list i can > manipulate in code, and which should of course be bound by those > constraints. Think of it similar as the case of an ordinary dictionary: There is conceptually a set here (the set of keys), but you cannot manipulate it directly, but only through the according dictionary methods. For an ordedred dictionary, there is conceptually a list (or more specifically a unique list). Again you should not manipulate it directly, but only through methods of the ordered dictionary. This sounds at first more complicated, but is in reality more easy. For instance, if I want to put the last two keys of an ordered dict d at the beginning, I would do it as d = d[:-2] + d[-2:]. With the list attribute (called "sequence" in odict, you would have to write: d.sequence = d.sequence[:-2] + d.sequence[-2:]. This is not only longer to write down, but you also have to know that the name of the attribute is "sequence". Python's strength is that you don't have to keep many details in mind because it has a small "basic vocabulary" and orthogonal use. I prefer the ordered dictionary does not introduce new concepts or attributes if everything can be done intuitively with the existing Python methods and operators. -- Christoph -- http://mail.python.org/mailman/listinfo/python-list
