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
> 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
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 o
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?
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
On Wed, Mar 4, 2009 at 1:44 PM, Greg Ewing 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 actually *is*.
Ple
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
___
Python-
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
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
Am 04.03.2009 14:25, Benji York schrieb:
> On Wed, Mar 4, 2009 at 3:01 AM, Glenn Linderman 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 y
Leif Walsh wrote:
On Wed, Mar 4, 2009 at 7:53 AM, 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.
Hm
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
On Wed, Mar 4, 2009 at 7:53 AM, 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.
Hmm, perhaps a b
On Wed, Mar 4, 2009 at 7:53 AM, 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
--
Cheers,
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 comparison
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 proble
On Wed, Mar 4, 2009 at 3:01 AM, Glenn Linderman 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 good
> name in som
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 orde
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.
Issues:
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),
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 o
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
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 dou
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 dou
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
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
so
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 dot
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
Python-Dev@python.org
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()) #
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 l
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
its
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".
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
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
http://mail.python.org
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 non
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 termino
On Tue, Mar 3, 2009 at 3:05 PM, Scott David Daniels
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
>>> cu
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 k
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. Sho
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
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.
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
[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
http://
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 po
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, Mar 3, 2009 at 12:02 PM, Raymond Hettinger 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 simply m
On Tue, March 3, 2009 11:54 am, Guido van Rossum wrote:
> On Tue, Mar 3, 2009 at 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 d
[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 e
On Tue, Mar 3, 2009 at 11:20 AM, Forest 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?
> Yes. It pops-off
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
v
On Mar 2, 2009, at 7:08 PM, Steve Holden wrote:
PS.: so is datetime.datetime a builtin then? :)
Another historic accident. Like socket.socket. :-(
A pity this stuff wasn't addressed for 3.0. Way too late now, though.
It may be too late to rename the existing accidents, but why not add
co
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 co
Guido van Rossum wrote:
> On Mon, Mar 2, 2009 at 3:43 PM, Raymond Hettinger 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
On Mon, Mar 2, 2009 at 3:52 PM, Raymond Hettinger 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 internal use ha
-
From: "Guido van Rossum"
To: "Raymond Hettinger"
Cc: ; "Armin Ronacher"
Sent: Monday, March 02, 2009 3:38 PM
Subject: Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections
ready for pronouncement
On Mon, Mar 2, 2009 at 3:13 PM, Raymond Hett
On Mon, Mar 2, 2009 at 3:43 PM, Raymond Hettinger 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
>> i
Hi,
Guido van Rossum 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. Maybe
[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
On Mon, Mar 2, 2009 at 3:13 PM, Raymond Hettinger 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.
>
> Traditio
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
2009/3/2 Armin Ronacher :
> Hi,
>
> Raymond Hettinger 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 out name as well, but I st
> 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
[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? Can
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
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 | Brisba
/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:
http://mail.python.org/mailman/options/python-dev/archive%40m
On 02/03/2009 22:28, Georg Brandl wrote:
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.)
Since the odict naming is already so prevalent in the wild, it seems to
me li
Steve Holden 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:
http://www.goog
Guido van Rossum 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
___
Python-Dev mai
2009/3/2 Armin Ronacher :
> Hi,
>
> Georg Brandl 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 wit
Benjamin Peterson wrote:
> 2009/3/1 Armin Ronacher :
[...]
>> 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 think that "odict" or
Hi,
Georg Brandl 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 with
Counte
On Mon, Mar 2, 2009 at 1:28 PM, Georg Brandl wrote:
> Benjamin Peterson schrieb:
>> 2009/3/1 Armin Ronacher :
>>> 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 r
Benjamin Peterson schrieb:
> 2009/3/1 Armin Ronacher :
>> 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.
>>
>> Annotate
2009/3/1 Armin Ronacher :
> 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 t
On Sun, 1 Mar 2009 19:13:27 + (UTC), Armin Ronacher
wrote:
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 chang
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 ordered
76 matches
Mail list logo
