Changes by Matthieu Labbé bugs.python@mattlabbe.com:
--
nosy: +matthieu.labbe
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5397
___
___
Forest Wilkinson for...@users.sourceforge.net added the comment:
I was just reading the PEP, and caught this bit:
Does OrderedDict.popitem() return a particular key/value pair?
Yes. It pops-off the most recently inserted new key and its
corresponding value.
Okay, but I'd also like a convenient
Georg Brandl ge...@python.org added the comment:
I wonder if, instead of all kinds of new APIs, the _keys list could just
be made public (under a different name of course).
Of course, that makes further optimization or a rewrite in C harder.
___
Python
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
The internal data structure *must* remain private so that we can build a
C replacement or switch to one of the other possible algorithms.
___
Python tracker rep...@bugs.python.org
Georg Brandl ge...@python.org added the comment:
The internal data structure *must* remain private so that we can build a
C replacement or switch to one of the other possible algorithms.
Even then the keys list could be offered as a property.
___
Python
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Forest, I've taken another look at what's involved and am inclined to
accept the idea. It can be done without mucking-up the regular dict API
and without precluding any of the other possible underlying algorithms.
I like
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Forest, for your use case I recommend copying the code to a new class
and replacing the _keys list with a deque so that you can efficiently
pop from the other end.
___
Python tracker
Forest Wilkinson for...@users.sourceforge.net added the comment:
Shouldn't popitem() allow the caller to choose which end from
which to pop?
Thinking it through a bit more, and LRU cache would actually need to
access the oldest item without necessarily removing it. Besides,
popitem() should
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
Removed file: http://bugs.python.org/file13221/od4.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5397
___
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
Removed file: http://bugs.python.org/file13228/od5.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5397
___
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
Removed file: http://bugs.python.org/file13229/od6.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5397
___
Armin Ronacher armin.ronac...@active-4.com added the comment:
Please no. We just decided to *not* extend the API. The PEP originally
had a well designed list of dict API extensions that already provided
exactly that. If we really want to provide access to that, we can roll
back to where we
Armin Ronacher armin.ronac...@active-4.com added the comment:
Please no. We just decided to *not* extend the API. The PEP originally
had a well designed list of dict API extensions that already provided
exactly that. If we really want to provide access to that, we can roll
back to where we
Changes by Armin Ronacher armin.ronac...@active-4.com:
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5397
___
___
Python-bugs-list mailing list
Georg Brandl ge...@python.org added the comment:
OK, disregard my suggestions, it's better not to have a property that
does almost exactly the same as keys().
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5397
Forest Wilkinson for...@users.sourceforge.net added the comment:
Agreed here. Thanks, gents.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5397
___
___
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
At Antoine's request, strengthened the tests in test_copying.
--
assignee: - rhettinger
Added file: http://bugs.python.org/file13229/od6.diff
___
Python tracker
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Attaching update reflecting Guido's change to __eq__().
Added file: http://bugs.python.org/file13231/od7.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5397
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Checked-in r70101 and r70102
--
resolution: - accepted
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5397
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5397
___
___
Python-bugs-list mailing list
Armin Ronacher armin.ronac...@active-4.com added the comment:
Maybe premature optimization but maybe it would make sense to implement
__eq__ like this:
def __eq__(self, other):
if isinstance(other, OrderedDict):
if not dict.__eq__(self, other):
return False
New submission from Raymond Hettinger rhettin...@users.sourceforge.net:
Here is a working patch implementing PEP372 ordered dictionaries.
--
components: Library (Lib)
files: od.diff
keywords: patch
messages: 82955
nosy: rhettinger
severity: normal
stage: patch review
status: open
title:
Georg Brandl ge...@python.org added the comment:
Doc nits:
* items are returned in the order they were first added: it should be
made clear that it matters when the *key* was first added
* An *OrderedDict* remembers order that entries were inserted: misses
a word somewhere?
* OrderDict should
Antoine Pitrou pit...@free.fr added the comment:
In SubclassMappingTests, MyOrderedDict should subclass OrderedDict
rather than dict, shouldn't it?
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5397
Armin Ronacher armin.ronac...@active-4.com added the comment:
@Georg
* eval()ing the repr() will not construct the dict in the same order
The alternative would be a list of dicts inside the constructor call,
but that feels ugly. defaultdict from the same module is not evaluable
at all, so I
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Thanks for the review comments guys. An updated patch is attached.
Added file: http://bugs.python.org/file13219/od2.diff
___
Python tracker rep...@bugs.python.org
Georg Brandl ge...@python.org added the comment:
I still see an OrderDict in the docs, and the TypeError in __init__
still needs to use % instead of ,.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5397
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Fixed.
Added file: http://bugs.python.org/file13220/od3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5397
___
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
Removed file: http://bugs.python.org/file13219/od2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5397
___
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
Removed file: http://bugs.python.org/file13217/od.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5397
___
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Added a few more tests.
Added file: http://bugs.python.org/file13221/od4.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5397
Changes by Raymond Hettinger rhettin...@users.sourceforge.net:
Removed file: http://bugs.python.org/file13220/od3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5397
___
Jim Jewett jimjjew...@users.sourceforge.net added the comment:
I would try to make it more explicit that updates do not reset the
order, but deleting a item and re-inserting it *does*. (So it isn't
the first insertion of the key, it is the first that hasn't yet been
followed by a deletion.)
Jim Jewett jimjjew...@users.sourceforge.net added the comment:
I would also recommend strengthening some of the tests with regard to
ordering stability across update vs delete-and-reinsert.
TestOrderedDict.test_update does verify that updated items are not
moved to the end, but the comment
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Jim, I updated the docs to talk cover delete-reinsert.
Also, added a few more tests as suggested but am leaving test_iterators,
test_popitem, and test_pop unchanged. It is enough to test
delete-reinsertion once or twice and
35 matches
Mail list logo
