On Wed, Wed, 4 Mar 2009 13:52:59 -0800, Guido van Rossum wrote:
On Wed, Mar 4, 2009 at 1:44 PM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
rdmur...@bitdance.com wrote:
I actually like StableDict best. ?When I hear that I think, ah, the
key order is stable in the face of insertions, unlike
On approximately 3/3/2009 11:22 PM, came the following characters from
the keyboard of Raymond Hettinger:
Perhaps the terminology should be
ordereddict -- what we have here
sorteddict -- hypothetical future type that keeps
itself sorted in key order
+1
-1
Introducing
On Wed, 4 Mar 2009 05:23:33 pm Glenn Linderman wrote:
The problem with the ordereddict/OrderedDict/odict is that there
are way too many possible orderings, and without being more
specific (InsertionSequenceOrderPreservingDictionary) people are
doing to think sort when they hear ordered.
For
On Mar 4, 2009, at 9:01 , Glenn Linderman wrote:
On approximately 3/3/2009 11:22 PM, came the following characters
from the keyboard of Raymond Hettinger:
Perhaps the terminology should be
ordereddict -- what we have here
sorteddict -- hypothetical future type that keeps
Hello all,
First a comment on-thread:
I can't wait to get an ordered dictionary in the stdlib! The discussion
regarding suggestions for the name appears to be ongoing. What about the
name 'orderdict' instead of 'ordereddict'?. It doesn't contain the double-d,
is slightly shorter, and I think a
Gisle Aas wrote:
Instead of introducing a sorteddict I would instead suggest that the
future should bring an odict with a sort method; possibly also
keys_sorted and items_sorted methods.
Instead of odict.sorted(), that can be spelled:
sorted(odict) # sort the keys
sorted(odict.values()) #
Beware, deleting an item from an OrderedDict (in the current
implementation) is O(N).
Am I correct in presuming that that would not be true of .popitem?
Yes. The popitem() method is O(1).
Raymond
___
Python-Dev mailing list
Raymond Hettinger wrote:
[...]
FWIW, PEP 372 has links to seven other independent implementations and
they all have names that are some variant spelling OrderedDict except
for one which goes by the mysterious name of StableDict.
Am still +1 on painting the class green with pink polka dots,
Steven D'Aprano wrote:
Gisle Aas wrote:
Instead of introducing a sorteddict I would instead suggest that the
future should bring an odict with a sort method; possibly also
keys_sorted and items_sorted methods.
Instead of odict.sorted(), that can be spelled:
sorted(odict) # sort the keys
Glenn Linderman wrote:
FIFOdict ? Yeah, that blows the capitalization scheme, way, way out.
[...]
It is suggestive of queue behavior, and the items are a queue if looked
at from insertion, and traversal perspectives, if I understand
correctly.
Why is this relevant? Insertion and traversal
Tennessee Leeuwenburg wrote:
Hello all,
First a comment on-thread:
I can't wait to get an ordered dictionary in the stdlib! The
discussion regarding suggestions for the name appears to be ongoing.
What about the name 'orderdict' instead of 'ordereddict'?. It doesn't
contain the double-d,
Tennessee Leeuwenburg wrote:
Hello all,
First a comment on-thread:
I can't wait to get an ordered dictionary in the stdlib! The
discussion regarding suggestions for the name appears to be ongoing.
What about the name 'orderdict' instead of 'ordereddict'?. It doesn't
contain the double-d,
Gisle Aas wrote:
On Mar 4, 2009, at 9:01 , Glenn Linderman wrote:
On approximately 3/3/2009 11:22 PM, came the following characters from
the keyboard of Raymond Hettinger:
Perhaps the terminology should be
ordereddict -- what we have here
sorteddict -- hypothetical future type that keeps
Raymond Hettinger wrote:
Perhaps the terminology should be
ordereddict -- what we have here
sorteddict -- hypothetical future type that keeps
itself sorted in key order
+1
FIFOdict ? Yeah, that blows the capitalization scheme, way, way out.
Issues:
* The
Lie Ryan wrote:
How about making odict ordered by insertion order, then provide an
optional argument for defining sorter? This optional argument must be a
function/lambda/callable object and must be the first argument.
As the PEP mentions (and Hrvoje brought up again already in this
thread), a
Steve Holden wrote:
Raymond Hettinger wrote:
Perhaps the terminology should be
ordereddict -- what we have here
sorteddict -- hypothetical future type that keeps
itself sorted in key order
+1
FIFOdict ? Yeah, that blows the capitalization scheme, way, way out.
On Wed, 4 Mar 2009 at 23:37, Lie Ryan wrote:
Steve Holden wrote:
Raymond Hettinger wrote:
Perhaps the terminology should be
ordereddict -- what we have here
sorteddict -- hypothetical future type that keeps
itself sorted in key order
+1
On Wed, Mar 4, 2009 at 3:01 AM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
C'mon folks, brainstorm, don't complain about ordereddict if you can't come
up with some alternatives for discussion!!! (and some reasons why the
suggestions might be good or bad) Even your bad ideas might trigger a
rdmurray at bitdance.com writes:
I actually like StableDict best. When I hear that I think, ah, the
key order is stable in the face of insertions, unlike a regular dict.
Nor can I at the moment think of an alternative explanation of what a
StableDict might be.
That said, I have no
Nick Coghlan wrote:
Lie Ryan wrote:
How about making odict ordered by insertion order, then provide an
optional argument for defining sorter? This optional argument must be a
function/lambda/callable object and must be the first argument.
or better yet, in the spirit of dumping cmp
On Wed, Mar 4, 2009 at 7:53 AM, rdmur...@bitdance.com wrote:
I actually like StableDict best. When I hear that I think, ah, the
key order is stable in the face of insertions, unlike a regular dict.
Nor can I at the moment think of an alternative explanation of what a
StableDict might be.
+1
On Wed, Mar 4, 2009 at 7:53 AM, rdmur...@bitdance.com wrote:
I actually like StableDict best. When I hear that I think, ah, the
key order is stable in the face of insertions, unlike a regular dict.
Nor can I at the moment think of an alternative explanation of what a
StableDict might be.
Lie Ryan wrote:
Isn't ordered dictionary essentially also an always sorted container?
It is always sorted depending on the order of insertion? I can't see any
technical reason why the data structure can't accommodate them both. Can
you point me to a discussion on this?
Appending an item at
Leif Walsh wrote:
On Wed, Mar 4, 2009 at 7:53 AM, rdmur...@bitdance.com wrote:
I actually like StableDict best. When I hear that I think, ah, the
key order is stable in the face of insertions, unlike a regular dict.
Nor can I at the moment think of an alternative explanation of what a
Am 04.03.2009 14:25, Benji York schrieb:
On Wed, Mar 4, 2009 at 3:01 AM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
C'mon folks, brainstorm, don't complain about ordereddict if you can't come
up with some alternatives for discussion!!! (and some reasons why the
suggestions might be good
Lie Ryan wrote:
Isn't ordered dictionary essentially also an always sorted container?
It is always sorted depending on the order of insertion? I can't see any
technical reason why the data structure can't accommodate them both. Can
you point me to a discussion on this?
My phrasing was a
Dennis Benzinger wrote:
I'd prefer encoding the order in the class name, therefore I suggest
(Ins|Insertion)(Order|Ordered)Dict, e.g. InsOrderDict. Abbreviating the
first group to simply I probably is too confusing because of the use of
I as a prefix for interfaces.
Except I just don't see
rdmur...@bitdance.com wrote:
I actually like StableDict best. When I hear that I think, ah, the
key order is stable in the face of insertions, unlike a regular dict.
But it still doesn't convey what the ordering actually *is*.
--
Greg
___
On Wed, Mar 4, 2009 at 1:44 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
rdmur...@bitdance.com wrote:
I actually like StableDict best. When I hear that I think, ah, the
key order is stable in the face of insertions, unlike a regular dict.
But it still doesn't convey what the ordering
Steven D'Aprano wrote:
I also can't think of an alternative
explanation, so thus far, it's resistant to false positive semantics.
The keys don't expire with time.
It's stable against accidental deletions.
It's stable against accidentally over-writing values.
Add to that:
The StableDict is
Terry Reedy wrote:
Lie Ryan wrote:
Isn't ordered dictionary essentially also an always sorted
container? It is always sorted depending on the order of insertion? I
can't see any technical reason why the data structure can't
accommodate them both. Can you point me to a discussion on this?
Hi Nick!
Am 04.03.2009 22:34, Nick Coghlan schrieb:
Dennis Benzinger wrote:
I'd prefer encoding the order in the class name, therefore I suggest
(Ins|Insertion)(Order|Ordered)Dict, e.g. InsOrderDict. Abbreviating the
first group to simply I probably is too confusing because of the use of
I
I'm looking forward to an ordered dictionary in the standard library,
especially for things like LRU caches. 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
On Tue, Mar 3, 2009 at 11:20 AM, Forest list8a.for...@tibit.com wrote:
I'm looking forward to an ordered dictionary in the standard library,
especially for things like LRU caches. I was just reading the PEP, and
caught this bit:
Does OrderedDict.popitem() return a particular key/value pair?
[Forest]
Okay, but I'd also like a convenient and fast way to find the oldest entry
in an OrderedDict, which I think I'd need for an LRU cache. Skimming the
current patch (od7.diff), I didn't notice one. Perhaps I simply missed
something. Shouldn't popitem() allow the caller to choose which
On Tue, March 3, 2009 11:54 am, Guido van Rossum wrote:
On Tue, Mar 3, 2009 at 11:20 AM, Forest list8a.for...@tibit.com wrote:
Okay, but I'd also like a convenient and fast way to find the oldest
entry
in an OrderedDict, which I think I'd need for an LRU cache. Skimming
the
current patch
On Tue, Mar 3, 2009 at 12:02 PM, Raymond Hettinger pyt...@rcn.com wrote:
[Forest]
Okay, but I'd also like a convenient and fast way to find the oldest entry
in an OrderedDict, which I think I'd need for an LRU cache. Skimming the
current patch (od7.diff), I didn't notice one. Perhaps I
I recommend that you either make this a
__private variable (signalling strongly that people shouldn't ever
reference it),
Will do. We want to make sure we can substitute a C implementation that has a completely different underlying structure (hash table
plus a doubly linked list).
Raymond
On Tue, March 3, 2009 11:20 am, Forest wrote:
Okay, but I'd also like a convenient and fast way to find the oldest entry
in an OrderedDict, which I think I'd need for an LRU cache. Skimming the
current patch (od7.diff), I didn't notice one. Perhaps I simply missed
something. Shouldn't
[Forest]
Perhaps a new method like getfirst() would be worth while here?
Guido already gave you a way to access the first item using the existing API.
Using next(iter(d)) also works.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
Giovanni Bajo wrote:
Just today, I was talking with a colleague (which is learning Python
right now) about ordered dict. His first thought was a dictionary that,
when iterated, would return keys in sorted order.
I wonder whether indexed list would be a more appropriate
name for what we're
Raymond Hettinger wrote:
[Forest]
Perhaps a new method like getfirst() would be worth while here?
Guido already gave you a way to access the first item using the existing
API.
Using next(iter(d)) also works.
Yep. I think messages are arriving out of order.
-1 on my own suggestion.
Greg Ewing wrote:
Giovanni Bajo wrote:
Just today, I was talking with a colleague (which is learning Python
right now) about ordered dict. His first thought was a dictionary
that, when iterated, would return keys in sorted order.
I wonder whether indexed list would be a more appropriate
Forest wrote:
On Tue, March 3, 2009 11:20 am, Forest wrote:
Okay, but I'd also like a convenient and fast way to find the oldest entry
in an OrderedDict, which I think I'd need for an LRU cache. Skimming the
current patch (od7.diff), I didn't notice one. Perhaps I simply missed
something.
Terry Reedy wrote:
I almost agree, except that the API uses the dict, not list, API.
Yes, as long as the API is dict-like, it really needs to
be thought of as a kind of dict.
Perhaps the terminology should be
ordereddict -- what we have here
sorteddict -- hypothetical future type that
On Tue, Mar 3, 2009 at 3:05 PM, Scott David Daniels
scott.dani...@acm.org wrote:
Forest wrote:
On Tue, March 3, 2009 11:20 am, Forest wrote:
Okay, but I'd also like a convenient and fast way to find the oldest
entry
in an OrderedDict, which I think I'd need for an LRU cache. Skimming the
On approximately 3/3/2009 4:51 PM, came the following characters from
the keyboard of Greg Ewing:
Terry Reedy wrote:
I almost agree, except that the API uses the dict, not list, API.
Yes, as long as the API is dict-like, it really needs to
be thought of as a kind of dict.
Perhaps the
Perhaps the terminology should be
ordereddict -- what we have here
sorteddict -- hypothetical future type that keeps
itself sorted in key order
+1
FIFOdict ? Yeah, that blows the capitalization scheme, way, way out.
Issues:
* The popitem() method is LIFO.
* In a
Guido van Rossum wrote:
Beware, deleting an item from an OrderedDict (in the current
implementation) is O(N).
Am I correct in presuming that that would not be true of .popitem?
___
Python-Dev mailing list
Python-Dev@python.org
2009/3/1 Armin Ronacher armin.ronac...@active-4.com:
Hi everybody,
PEP 372 was modified so that it provides a simpler API (only the dict API
to be exact) and it was decided to start with a Python-only implementation
and replace it with a C version later if necessary.
Annotated changes from
Benjamin Peterson schrieb:
2009/3/1 Armin Ronacher armin.ronac...@active-4.com:
Hi everybody,
PEP 372 was modified so that it provides a simpler API (only the dict API
to be exact) and it was decided to start with a Python-only implementation
and replace it with a C version later if
On Mon, Mar 2, 2009 at 1:28 PM, Georg Brandl g.bra...@gmx.net wrote:
Benjamin Peterson schrieb:
2009/3/1 Armin Ronacher armin.ronac...@active-4.com:
Hi everybody,
PEP 372 was modified so that it provides a simpler API (only the dict API
to be exact) and it was decided to start with a
Hi,
Georg Brandl g.brandl at gmx.net writes:
We're already quite inconsistent with type name casing in the collections
module, so it wouldn't matter so much. (Though I'd find symmetry with
defaultdict pleasing as well.)
We either have the way to be consistent with defaultdict and dict or
Benjamin Peterson wrote:
2009/3/1 Armin Ronacher armin.ronac...@active-4.com:
[...]
The corresponding issue in the tracker: http://bugs.python.org/issue5397
Link to the PEP: http://www.python.org/dev/peps/pep-0372/
Anything else that should be done?
Have you considered naming? I would
2009/3/2 Armin Ronacher armin.ronac...@active-4.com:
Hi,
Georg Brandl g.brandl at gmx.net writes:
We're already quite inconsistent with type name casing in the collections
module, so it wouldn't matter so much. (Though I'd find symmetry with
defaultdict pleasing as well.)
We either have
Guido van Rossum guido at python.org writes:
+1 for odict. Somehow I thought that was the name proposed by the PEP.
It originally was, Raymond wanted to change it. I would still vote for odict if
that's still possible :)
Regards,
Armin
___
Steve Holden steve at holdenweb.com writes:
Surely that's just a thinko in the subject line? The PEP specifies
ordered dictionary and nobody has been talking about directories.
Actually, the initial version of the PEP had that typo in the topic. Guess I
copy pasted wrong again:
/bikeshedding
Yes. Also we need to paint it green with pink polka dots :-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Guido van Rossum wrote:
+1 for odict. Somehow I thought that was the name proposed by the PEP. :-(
The examples in the PEP used 'odict' (until recently), but the patch was
for OrderedDict.
I don't personally mind either way.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com |
Raymond Hettinger wrote:
/bikeshedding
Yes. Also we need to paint it green with pink polka dots :-)
Or should that be pink with green polka dots? ;)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
[Nick Coghlan]
The examples in the PEP used 'odict' (until recently), but the patch was
for OrderedDict.
As an experiment, try walking down the hall asking a few programmers who aren't in this conversion what they think
collections.odict() is?
Is it a class or function? What does it do?
Is it a class or function? What does it do? Can the English as second
language folks guess what the o stands for? Is it a builtin or pure
python? My guess is that the experiment will be informative.
I'll do that tomorrow (if I manage to remember). My guess is that
ordered dictionary is as
2009/3/2 Armin Ronacher armin.ronac...@active-4.com:
Hi,
Raymond Hettinger python at rcn.com writes:
When we use the class, we typically only spell-out the constructor
once while actually using the returned
object many times. So,
have we really saved any typing?
I'm fine with the typed
Unfortunately PEP 8 never really took off naming-wise, so we're mostly following
the reuse the naming scheme from existing code in the same module rule, and I
think there lowercase wins, thanks to defaultdict.
Traditionally, the all lowercase name referred to a C type. The other classes
in
On Mon, Mar 2, 2009 at 3:13 PM, Raymond Hettinger pyt...@rcn.com wrote:
Unfortunately PEP 8 never really took off naming-wise, so we're mostly
following
the reuse the naming scheme from existing code in the same module rule,
and I
think there lowercase wins, thanks to defaultdict.
[GvR]
*Maybe* the built-in status should guide the
capitalization, so only built-in types are lowercase (str, int, dict
etc.).
That makes sense.
Anyway, it seems the collections module in particular is already
internally inconsistent -- NamedTuple vs. defaultdict.
FWIW, namedtuple() is a
Hi,
Guido van Rossum guido at python.org writes:
Anyway, it seems the collections module in particular is already
internally inconsistent -- NamedTuple vs. defaultdict. In a sense
defaultdict is the odd one out here, since these are things you import
from some module, they're not built-in.
On Mon, Mar 2, 2009 at 3:43 PM, Raymond Hettinger pyt...@rcn.com wrote:
[GvR]
*Maybe* the built-in status should guide the
capitalization, so only built-in types are lowercase (str, int, dict
etc.).
That makes sense.
Anyway, it seems the collections module in particular is already
Quick question? Is PEP 8 still current for what is being done in Py3.x?
I just took a quick look and it says:
Class Names
Almost without exception, class names use the CapWords convention.
Classes for internal use have a leading underscore in addition.
- Original Message
On Mon, Mar 2, 2009 at 3:52 PM, Raymond Hettinger pyt...@rcn.com wrote:
Quick question? Is PEP 8 still current for what is being done in Py3.x?
I just took a quick look and it says:
Class Names
Almost without exception, class names use the CapWords convention.
Classes for
Guido van Rossum wrote:
On Mon, Mar 2, 2009 at 3:43 PM, Raymond Hettinger pyt...@rcn.com wrote:
[GvR]
*Maybe* the built-in status should guide the
capitalization, so only built-in types are lowercase (str, int, dict
etc.).
That makes sense.
Anyway, it seems the collections module in
On Mon, 02 Mar 2009 14:36:32 -0800, Raymond Hettinger wrote:
[Nick Coghlan]
The examples in the PEP used 'odict' (until recently), but the patch
was for OrderedDict.
As an experiment, try walking down the hall asking a few programmers who
aren't in this conversion what they think
Hi everybody,
PEP 372 was modified so that it provides a simpler API (only the dict API
to be exact) and it was decided to start with a Python-only implementation
and replace it with a C version later if necessary.
Annotated changes from earlier versions of the PEP:
- the extra API for
73 matches
Mail list logo
