On Wed, 2005-11-23 at 15:17, Christoph Zwerschke wrote: > Bengt Richter wrote: > > I think the concept has converged to a replace-or-append-by-key ordering > > of key:value items with methods approximately like a dict. We're now > > into usability aspects such as syntactic sugar vs essential primitives, > > and default behaviour vs selectable modes, ISTM. > > Yes, and we would be good if we do not stop the discussion at this point > with nothing, but really create such a sophisticated implementation. > Whether it will become popular or go to the standard lib some day is a > completely different question. > > > E.g., it might be nice to have a mode that assumes d[key] is > d.items()[k][1] when > > key is an integer, and otherwise uses dict lookup, for cases where > the use > > case is just string dict keys. > > I also thought about that and I think PHP has that feature, but it's > probably better to withstand the temptation to do that. It could lead to > an awful confusion if the keys are integers.
Thus quoth the Zen of Python: "Explicit is better than implicit." "In the face of ambiguity, refuse the temptation to guess." With those in mind, since an odict behaves mostly like a dictionary, [] should always refer to keys. An odict implementation that wants to allow access by numeric index should provide explicitly named methods for that purpose. -Carsten -- http://mail.python.org/mailman/listinfo/python-list
