|
From: Fuzzyman <fuz...@vo...> - 2005-11-24 15:45:57
|
Hello Nicola, (et al) This is still vaguely on topic for this list. After completing the (next phase of) OrderedDict improvements I need to decide how many of those improvements to move into ConfigObj. (And yes Nicola, I *do* remember your suggestion that I derive ConfigObj from OrderedDict - and I *still* don't want ConfigObj to depend on it). What about this suggestion. It sounds a little esoteric to me - but if you think it's worth the effort I'll do it. We could implement the ``keys`` and ``values`` methods as custom objects with all the sequence methods. (With error checking so you can't mutate the keys so that they don't reflect the internal contents of the odict). We would also implement ``__getitem__``, ``__setitem__``, and ``__call__`` such that you can directly index (slice, delete, etc) members as if it was a list. You can also call it as if it was a method - including passing it a sequence to replace the current keys with. We would presumably have to implement ``__setattr__`` on the main OrderedDict so that : d1 = OrderedDict(sequence_of_tuples) d1.keys = a_list is the same as : d1 = OrderedDict(sequence_of_tuples) d1.keys(a_list) What should ``d1.keys(a_list)`` return ? (The same as d1.keys() I guess - except with the new key set). We (I) would still implement slicing, insert, reverse, and sort for the OrderedDict class itself. Fredrik Lundh pointed out the performance impact of adding to many layers above the C implementation. I have no idea how relevant that is to the suggestion I've just made. :-) (How many method calls would indexing or assigning to the ``keys`` object actually result in 'under the hood' ?) All the best, Fuzzyman http://www.voidspace.org.uk/python/index.shtml |