Alex Martelli wrote: > Fuzzyman <[EMAIL PROTECTED]> wrote: > ... > > > - the internal keys list should be hidden > > > > I disagree. It is exposed so that you can manually change the order > > (e.g. to create a "sorted" dict, rather than one ordered by key > > insertion). > > > > What do you *gain* by hiding it ? > > Freedom of implementation, of course. E.g., I can perhaps get better > performance by keeping a red-black tree of (insertiontime,key) pairs, so > for example deleting a key is O(log(N)) rather than O(N) as it would > have to be if the sequence had to be kept as a Python list. > > What ELSE do you ever gain by enforcing abstraction and information > hiding? Conceptual integrity and implementation freedom... >
The poster I was replying to inferred that we should hide it to protect him from breaking it. :-) Your reason is much more valid than the one I inferred. (And probably worth chanign the code for). > > > > - list methods should be mixed in instead > > > > Hmm... I did consider this. Which list methods would you consider > > appropriate ? > > > > The difficulty is that integers are valid keys for a dictionary. > > Perhaps a subclass that uses integers as indexes instead... > > What about allowing slicing, taking advantage of the fact that slices > are NOT valid dictionary keys? Hmm... ok, simple enough to implement. What would anyone *use* it for though ? > Presumably sort and reverse methods are also desired. > Yeah - good idea. Insert is also good - I can't remember if we provide this or not. Thanks Fuzzyman http://www.voidspac.org.uk/python/index.shtml > > You can always perform list operations on the ``sequence`` attribute of > > course. > > But NOT having to expose .sequence as a real mutable list whose changes > affect ordering has many advantages, as above noticed. > > > Alex -- http://mail.python.org/mailman/listinfo/python-list