Tom Anderson wrote:
> 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 I am now in favour of hiding hte sequence attribute. You will be able to mutate the the keys list through : d1 = OrderedDict(some_sequence_of_items) keys = d1.keys() keys.sort() # or other mutation d1.keys(keys) Admittedly this is a lot slower than : d1 = OrderedDict(some_sequence_of_items) d1.sequence.sort() *but* it frees the squence attribute from any implementation details. All the best, Fuzzyman http://www.voidspace.org.uk/python/index.shtml > 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
