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 dete
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
>
> [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
[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 bef
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 th
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 Thu, 2005-03-10 at 01:29, Raymond Hettinger wrote:
> Or the implementation can have a switch to choose between keep-first
> logic or replace logic.
This is what I meant by my previous follow up: while the concept of "an
ordered dictionary" is nice and seemingly generic enough, in practice I
su
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).
>
>
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'
semantic
"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
> > 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
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
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 dup
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 f
Thomas Heller <[EMAIL PROTECTED]> wrote:
> Steven Bethard <[EMAIL PROTECTED]> writes:
>
>> What use do you have for it other than filtering
>> duplicates from a list while retaining order?
>
> If this were the only use case, you are right. I cannot
> remember the use case I once had right now, a
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 Ordere
[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 stdlib, but it's another use case. Each dict
k
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 t
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 t
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 filtering
dupli
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 original
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 tha
James Y Knight wrote:
I use ordered dictionaries for testing. With an ordered dict I can
string compare the output of my program to what is expected. Without an
ordered dict, I'd have to re-parse the output and order it, which would
require some complicated code that's just as likely to be wrong
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 s
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.
I
Thomas Heller <[EMAIL PROTECTED]> wrote:
> Steven Bethard <[EMAIL PROTECTED]> writes:
>
> > What use do you have for it other than filtering
> > duplicates from a list while retaining order?
>
> If this were the only use case, you are right. I cannot remember the
> use case I once had right now
Steven Bethard <[EMAIL PROTECTED]> writes:
> 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 use
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 t
[About an ordered dictionary]
> 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?
Greg Ward <[EMAIL PROTECTED]> writes:
> +1 on a cookbook entry. +0 on adding to stdlib.
"Martin v. Löwis"
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.
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
On 09 March 2005, Delaney, Timothy C (Timothy) said:
> For those who don't know, LinkedHashSet and LinkedHashMap are simply
> hashed sets and maps that iterate in the order that the keys were added
> to the set/map. I almost invariably use them for the above scenario -
> removing duplicates without
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 o
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 where to put
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 where to put them. It was pointed out that the obvious place
would be the co
34 matches
Mail list logo
