Anthony Baxter wrote:
On Thursday 10 March 2005 17:29, Raymond Hettinger wrote:
Or the implementation can have a switch to choose between keep-first
logic or replace logic.
The latter seems a bit odd to me. The key position would be determined
by the first encountered while the value would be
Delaney, Timothy C (Timothy) [EMAIL PROTECTED] writes:
Set: Items are iterated over in the order that they are added. Adding an
item that compares equal to one that is already in the set does not
replace the item already in the set, and does not change the iteration
order. Removing an item,
Delaney, Timothy C (Timothy) wrote:
OTOH, ordered set and ordered dict implies different things to
different people - usually sorted rather than the order things were
put in. Perhaps temporally-ordered ;)
OTGH*, I would expect an OrderedDict / OrderedSet to have 'add to the end'
semantics, but
On Wed, 2005-03-09 at 19:39, Tommy Burnette wrote:
I'd say I'm +0. fwiw- I've been using a locally-rolled OrderedDict
implementation for the last 5-6 years in which insertion order is the
only order respected. I use it all over the place (in a code base of
~60k lines of python code).
so
I would LOVE for **kwargs to be an ordered dict. It would allow me to
write code like this:
.class MyTuple:
.def __init__(self, **kwargs):
.self.__dict__ = ordereddict(kwargs)
.
.def __iter__(self):
.for k, v in self.__dict__.items():
.yield v
.
.t = MyTuple(r
On Thursday 10 March 2005 17:29, Raymond Hettinger wrote:
Or the implementation can have a switch to choose between keep-first
logic or replace logic.
The latter seems a bit odd to me. The key position would be determined
by the first encountered while the value would be determined by the
[BJörn Lindqvist]
I would LOVE for **kwargs to be an ordered dict. It would allow me to
write code like this:
.class MyTuple:
.def __init__(self, **kwargs):
.self.__dict__ = ordereddict(kwargs)
This doesn't work. The kwargs are already turned into a regular
dictionary before
Delaney, Timothy C (Timothy) wrote:
Does anyone else think it would be worthwhile adding these to
collections, or should I just make a cookbook entry?
-0 for the addition to the collections module, -1 on the specific
name.
Java made a *big* mistake by putting Hash into the names of these
things.
Thomas Heller [EMAIL PROTECTED] wrote:
[About an ordered dictionary]
[snip]
I cannot understand why people are against adding it to stdlib (after
the name, the implementation, and the exact place have been decided).
It's certainly a useful data type, isn't it?
Well, that was basically the
On Mar 9, 2005, at 4:19 PM, Thomas Heller wrote:
If this were the only use case, you are right. I cannot remember the
use case I once had right now, and probably the code has been rewritten
anyway. But I assume use cases exist, otherwise there weren't so many
recipes for the ordered dictionary.
Thomas Heller wrote:
I cannot understand why people are against adding it to stdlib (after
the name, the implementation, and the exact place have been decided).
It's certainly a useful data type, isn't it?
It depends on the precise semantics. You often want a dictionary where
the keys come out in
Steven Bethard wrote:
Thomas Heller [EMAIL PROTECTED] wrote:
[About an ordered dictionary]
Well, that was basically the question I posed. So far I've seen only
one use for it, and that one is better served by adding a function to
itertools. What use do you have for it other than
John Williams wrote:
The other use case I have is for dealing with data where the iteration
order doesn't matter to the program but it does matter to users. For
instance, consider the ConfigParser's write method. Any ordering of
values in the output is functionally equivalent, but the
I'd say I'm +0. fwiw- I've been using a locally-rolled OrderedDict
implementation for the last 5-6 years in which insertion order is the
only order respected. I use it all over the place (in a code base of
~60k lines of python code).
so there's another use case for you. bust as you say, easy
On Wed, Mar 09, 2005, Tommy Burnette wrote:
I'd say I'm +0. fwiw- I've been using a locally-rolled OrderedDict
implementation for the last 5-6 years in which insertion order is the
only order respected. I use it all over the place (in a code base of
~60k lines of python code).
so there's
On Wed, Mar 09, 2005, Raymond Hettinger wrote:
[Aahz]
Gee, I just found out I could have used an OrderedDict today. (We're
using a dict that we're now having to add an auxilliary list to to track
when keys are added.) (This isn't particularly an argument in favor of
adding OrderedDict to
Jeff Bauer wrote:
I'm not specifically lobbying for its inclusion in
stdlib, but I often find an ordered dict useful when I
want both ordered and random access, e.g. situations:
- database table fields/attributes
- drop down field selectors
Yep - these are also cases that are
Steven Bethard wrote:
def filterdups(iterable):
seen = set()
for item in iterable:
if item not in seen:
seen.add(item)
yield item
Adding this to, say, itertools would cover all my use cases. And as
long as you don't have too many duplicates,
Delaney, Timothy C (Timothy) [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
def filterdups(iterable):
seen = set()
for item in iterable:
if item not in seen:
seen.add(item)
yield item
Adding this to, say, itertools would cover all my
If I read the proposal correctly, order would be determined by when
the
key was first encountered. Presumably, that would mean that the
related
value would also be the first encountered (not overridden by
later-added
keys as dictated by your business requirements).
Hm Guess
Steven Bethard wrote:
Delaney, Timothy C (Timothy) [EMAIL PROTECTED] wrote:
The perennial how do I remove duplicates from a list topic came up on
c.l.py and in the discussion I mentioned the java 1.5 LinkedHashSet and
LinkedHashMap. I'd thought about proposing these before, but couldn't
think of
Greg Ward wrote:
I'll attach another approach to the same problem, an ordered
dictionary object. I believe the semantics of
adding/readding/deleting keys is the same as java.util.LinkedHashMap
-- certainly it seems the most sensible and easy-to-implement
semantics.
That's essentially the
22 matches
Mail list logo
