PEP 372 -- Adding an ordered directory to collections

[Paul McGuire]

1. With the current dict, the following code

a = { "A" : 1, "B" : 2 }
b = { "B" : 2, "A" : 1 }

a==b evaluates to  True.  I assume that if these were odicts, this
would evaluate to False.

2. Will odict.byindex support slicing?

3. Will odict inherit from dict?

4. The current dict API (as of Python 2.5) is given by dir as:

['__class__', '__cmp__', '__contains__', '__delattr__', '__delitem__',
'__doc__', '__eq__', '__ge__', '__getattribute__', '__getitem__',
'__gt__', '__hash__', '__init__', '__iter__', '__le__', '__len__',
'__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__',
'__repr__', '__setattr__', '__setitem__', '__str__', 'clear', 'copy',
'fromkeys', 'get', 'has_key', 'items', 'iteritems', 'iterkeys',
'itervalues', 'keys', 'pop', 'popitem', 'setdefault', 'update',
'values']

If I read your PEP correctly, you propose adding:

byindex
sort
reverse
__reverse__ (should be '__reversed__', to match list's reverse
iterator)

(This isn't really a question, your PEP was not completely explicit
about what odict's API would be, so I thought enumerating what dict
does currently might illuminate some other unresolved aspects of
odict.  For instance, since odict is somewhat list-like in its notion
of keys and values, will pop support list-like popping as well as what
dict currently provides?  Will you need a 'popbyindex' for the same
reason you need 'byindex', so that you have unambiguous lookup of
items by index vs. by key.  Perhaps doing dir(list) will help you to
see other items to resolve/clarify.)

5. The more I think and write about this, the more struck I am at the
similarity of odict and the ParseResults class in pyparsing.  For
instance, in ParseResults, there is also support for dict-style and
list-style item referencing, and I chose to restrict some cases so
that using [] notation would not be ambiguous.  You might want to add
pyparsing.ParseResults as another reference of current "odicts in the
wild" (although ParseResults implements quite a bit of additional
behavior that would not be required or necessarily appropriate for
odict).

I vote +0 on this PEP - I've never personally needed an odict, but I
can see how some of the XML and ORM coding would be simplified by one.

-- Paul

(I could go either way on the name 'odict' or 'ordereddict'.  Given
the desire for this to evenutally become a built-in, keep the name
short.  On the other hand, collections already has 'defaultdict', so
is 'ordereddict' so bad?)