On Tue, 22 Nov 2005, Christoph Zwerschke wrote: > One implementation detail that I think needs further consideration is in > which way to expose the keys and to mix in list methods for ordered > dictionaries. > > In Foord/Larosa's odict, the keys are exposed as a public member which > also seems to be a bad idea ("If you alter the sequence list so that it > no longer reflects the contents of the dictionary, you have broken your > OrderedDict"). > > 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.).
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. I think the way to do it is to have a sequence property (which could be a managed attribute to prevent outright clobberation) which walks like a list, quacks like a list, but is in fact a mission-specific list subtype whose mutator methods zealously enforce the invariants guaranteeing the odict's integrity. I haven't actually tried to write such a beast, so i don't know if this is either of possible and straightforward. tom -- When I see a man on a bicycle I have hope for the human race. -- H. G. Wells -- http://mail.python.org/mailman/listinfo/python-list