On 1 Dec 2005 01:48:56 -0800, "Fuzzyman" <[EMAIL PROTECTED]> wrote:
>
>Christoph Zwerschke wrote:
>>
>
>Hello Christoph,
>
>> I think re-ordering will be a very rare use case anyway and slicing even
>> more. As a use case, I think of something like mixing different
>> configuration files and defau
On 1 Dec 2005 03:53:27 -0800, "Fuzzyman" <[EMAIL PROTECTED]> wrote:
>Hmmm... it would be interesting to see if these tests can be used with
>odict.
I assume you are referring to the pytest tests I posted, though I would
need some of the context you snipped to me more sure ;-)
Anyway, with some ch
> The semantics of assigning slices
> to d.keys[i:j] and d.values[i:j] are kind of tricky when the size changes
> and/or key names match or don't match in various ways, or the incoming
> data represents collapsing redundant keys that are legal sequential assignment
> overrides but change the size,
Hmmm... it would be interesting to see if these tests can be used with
odict.
The odict implementation now has full functionality by the way.
Optimisations to follow and maybe a few *minor* changes.
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
--
http://mail.python.org/mailman/listi
Christoph Zwerschke wrote:
>
Hello Christoph,
> I think re-ordering will be a very rare use case anyway and slicing even
> more. As a use case, I think of something like mixing different
> configuration files and default configuration parameters, while trying
> to keep a certain order of paramet
On Tue, 29 Nov 2005 23:30:45 +0100, Christoph Zwerschke <[EMAIL PROTECTED]>
wrote:
>I had the same idea to create a py.test to verify and compare various
>implementations. The doctests in odict.py are nice, but you can't use
>them for this purpose and they may not test enough. It would be also
I had the same idea to create a py.test to verify and compare various
implementations. The doctests in odict.py are nice, but you can't use
them for this purpose and they may not test enough. It would be also
good to have something for testing and comparing performance.
-- Christoph
--
http://
On Sun, 27 Nov 2005 12:00:23 +0100, Christoph Zwerschke <[EMAIL PROTECTED]>
wrote:
>Bengt Richter wrote:
>
>>>d.keys[:] = newkeyseq
>>
>> Do you really mean just re-ordering the keys without a corresponding
>> reording of values??
>> That would be a weird renaming of all values. Or do you means
Bengt Richter schrieb:
> OTOH,
> >>> {}[:]
> Traceback (most recent call last):
>File "", line 1, in ?
> TypeError: unhashable type
> I.e., slices are not valid keys for ordinary dicts, and slices tie in
> very well with the ordered aspect of ordered dicts, so that's an
> argument for permi
Note that I've done two things with the Foord/Larosa dict. ;-)
I've implemented slicing, including slice assignment and deletion. I've
also 'hidden' ``sequence``, but you can pass arguments to keys, values
and items.
I've done a second (experimental) implementation of a custom keys
object. This i
Christoph Zwerschke wrote:
> I will assume that d has is a Foord/Larosa ordered dict with "sequence"
> attribute in the following.
>
> Then, with other words,
>
> d.keys[:] = newkeyseq
>
> should do the same as:
>
> d.sequence = newkeyseq
At least in the case where newkeyseq is a permutation
Bengt Richter wrote:
>>d.keys[:] = newkeyseq
>
> Do you really mean just re-ordering the keys without a corresponding reording
> of values??
> That would be a weird renaming of all values. Or do you means that any key
> should still
> retrieve the same value as before if used as d[key]? In whic
On Fri, 25 Nov 2005 19:42:49 +, Tom Anderson <[EMAIL PROTECTED]> wrote:
>On Wed, 23 Nov 2005, Carsten Haese wrote:
>
>> On Wed, 2005-11-23 at 15:17, Christoph Zwerschke wrote:
>>> Bengt Richter wrote:
>>>
>>> > E.g., it might be nice to have a mode that assumes d[key] is
>>> d.items()[k][1] wh
On Thu, 24 Nov 2005 18:42:45 +0100, Christoph Zwerschke <[EMAIL PROTECTED]>
wrote:
>Bengt Richter schrieb:
>
>>>d.setvalues((13, 14)) ==> d = OrderedDict((1, 13), (2, 14))
>
>> The implication above is that OrderedDict takes an *args argument,
>> but really it takes a single argument that is a se
On Fri, 25 Nov 2005, Christoph Zwerschke wrote:
> Tom Anderson wrote:
>
>> True, but that's not exactly rocket science. I think the rules governing
>> when your [] acts like a dict [] and when it acts like a list [] are vastly
>> more complex than the name of one attribute.
>
> I think it's not
Tom Anderson wrote:
> True, but that's not exactly rocket science. I think the rules governing
> when your [] acts like a dict [] and when it acts like a list [] are
> vastly more complex than the name of one attribute.
I think it's not really rocket science either to assume that an ordered
di
It seems everybody is in full agreement here.
I have the same mixed feeling about letting keys/values/items become
both managed list attributes and still returning copies of the lists
when called in the usual way as methods.
I don't know any precedent for doing things that way and i'm unsure
w
Tom Anderson schrieb:
> Maybe we should call it a 'sequenced dictionary' to fit better with
> pythonic terminology?
That's not such a bad idea. Note that it is called like that in the
Python version of the "Programming Language Examples Alike Cookbook":
http://pleac.sourceforge.net/pleac_pytho
On Wed, 23 Nov 2005, Christoph Zwerschke wrote:
> Tom Anderson wrote:
>
>>> I think it would be probably the best to hide the keys list from the
>>> public, but to provide list methods for reordering them (sorting, slicing
>>> etc.).
>>
>> one with unusual constraints, so there should be a list
On Wed, 23 Nov 2005, Carsten Haese wrote:
> On Wed, 2005-11-23 at 15:17, Christoph Zwerschke wrote:
>> Bengt Richter wrote:
>>
>> > E.g., it might be nice to have a mode that assumes d[key] is
>> d.items()[k][1] when
>> > key is an integer, and otherwise uses dict lookup, for cases where
>> the us
On Wed, 23 Nov 2005, Christoph Zwerschke wrote:
> Alex Martelli wrote:
>
>> However, since Christoph himself just misclassified C++'s std::map as
>> "ordered" (it would be "sorted" in this new terminology he's now
>> introducing), it seems obvious that the terminological confusion is
>> rife.
>
Fuzzyman <[EMAIL PROTECTED]> wrote:
...
> If you slice an ordered dictionary, I assume you would expect to get an
> ordered dictionary back ?
That would be helpful, yes, though there are precedents for types whose
slicing doesn't return an instance of that type (e.g. slices of an mmap
are insta
Fuzzyman wrote:
> That means making keys, values, and items custom objects.
> Creating a new instance would have the overhead of creating 4 new
> objects instead of just 1. Is the added convenience worth it ? (Plus
> the extra layers of method calls for each access).
I'm not sure about that eithe
Sure - that was just an example of mutating the keys list without
having direct access to it.
If keys was implemented as an object (with a ``__call__`` method) then
we could also implement sequence methods on it - making it easier to
mutate the keys/values/items directly.
All the best,
Fuzzyman
Alex Martelli wrote:
> Fuzzyman <[EMAIL PROTECTED]> wrote:
>
> > There is already an update method of course. :-)
> >
> > Slicing an ordered dictionary is interesting - but how many people are
> > actually going to use it ? (What's your use case)
>
> I detest and abhor almost-sequences which can't
Sure - that was just an example of mutating the keys list without
having direct access to it.
If keys was implemented as an object (with a ``__call__`` method) then
we could also implement sequence methods on it - making it easier to
mutate the keys/values/items directly.
All the best,
Fuzzyman
Le ruego me perdone.
replace('haber', random.choice('tener', 'hacer', 'lograr'))
Mi espanol es peor que mi python.
-- Christoph
--
http://mail.python.org/mailman/listinfo/python-list
Christoph Zwerschke wrote:
> Fuzzyman schrieb:
> > d.keys() will still return a copy of the list, so d.keys()[i] will
> > still be slower than d.sequence[i]
>
> Right, I forgot that. Bengt suggested to implement __call__ as well as
> __getitem__ and __setitem__ for keys, values and items.
>
> In
"hacer" probablemente.
DCA.
Piet van Oostrum wrote:
> > Christoph Zwerschke <[EMAIL PROTECTED]> (CZ) escribió:
>
> >CZ> Eso es exactamente lo que yo queria haber!
>
> ¿Haber? ¿Tener? :=(
> --
> Piet van Oostrum <[EMAIL PROTECTED]>
> URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
> Priv
Fuzzyman schrieb:
> d.keys() will still return a copy of the list, so d.keys()[i] will
> still be slower than d.sequence[i]
Right, I forgot that. Bengt suggested to implement __call__ as well as
__getitem__ and __setitem__ for keys, values and items.
In this case, you could very effectively acc
Bengt Richter schrieb:
>>d.setvalues((13, 14)) ==> d = OrderedDict((1, 13), (2, 14))
> The implication above is that OrderedDict takes an *args argument,
> but really it takes a single argument that is a sequence of k,v pairs,
> (and maybe some keyword options).
Right. Interpret it as a short no
Fuzzyman wrote:
> You will be able to mutate the the keys list through :
>
> d1 = OrderedDict(some_sequence_of_items)
> keys = d1.keys()
> keys.sort() # or other mutation
> d1.keys(keys)
>
> Admittedly this is a lot slower than :
>
> d1 = OrderedDict(some_sequence_of_items)
> d1.sequence.sort()
Bengt Richter wrote:
> On Wed, 23 Nov 2005 23:00:29 +0100, Christoph Zwerschke <[EMAIL PROTECTED]>
> wrote:
>
[snip..]
> I think also that d1==d2 should effectively be implemented as d1[:] == d2[:]
> -- i.e, compare
> the item lists to implement comparisons.
>
IIUC then the odict effectively alr
d.keys() will still return a copy of the list, so d.keys()[i] will
still be slower than d.sequence[i]
Slicing shouldn't be too much slower though.
All the best,
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
--
http://mail.python.org/mailman/listinfo/python-list
Fuzzyman schrieb:
> I'm going to add some of the sequence methods. I'm *not* going to allow
> indexing, but I will allow slicing.
>
> You can also do d[d.keys()[i]]
>
> This provides two ways of fetching values by index, so I don't want to
> add another.
And this would be probably faster than d
On Wed, 23 Nov 2005 23:00:29 +0100, Christoph Zwerschke <[EMAIL PROTECTED]>
wrote:
>Fuzzyman wrote:
>
>> So what do you want returned when you ask for d1[1] ? The member keyed
>> by 1, or the item in position 1 ?
>
>In case of conflict, the ordered dictionary should behave like a
>dictionary, no
Tom Anderson wrote:
> On Tue, 22 Nov 2005, Christoph Zwerschke wrote:
>
> > One implementation detail that I think needs further consideration is in
> > which way to expose the keys and to mix in list methods for ordered
> > dictionaries.
> >
> > In Foord/Larosa's odict, the keys are exposed as a
Duncan Booth schrieb:
> On IE this will go through elements in the order 0, 1, 2, 4, 3.
Oops! I bet most people would not expect that, and it is probably not
mentioned in most Javascript tutorials. I think this is a weakpoint of
the ECMA definition, not MSIE.
-- Christoph
--
http://mail.python
By the way, Nicola and I will be working on an improving odict in line
with several of the suggestions in this thread.
See :
http://www.voidspace.org.uk/python/weblog/arch_d7_2005_11_19.shtml#e140
All the best,
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
--
http://mail.python.org/m
> Christoph Zwerschke <[EMAIL PROTECTED]> (CZ) escribió:
>CZ> Eso es exactamente lo que yo queria haber!
¿Haber? ¿Tener? :=(
--
Piet van Oostrum <[EMAIL PROTECTED]>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listi
Carsten Haese wrote:
> On Wed, 23 Nov 2005 23:39:22 +0100, Christoph Zwerschke wrote
> > Carsten Haese schrieb:
> >
> > > Thus quoth the Zen of Python:
> > > "Explicit is better than implicit."
> > > "In the face of ambiguity, refuse the temptation to guess."
> > >
> > > With those in mind, since
Christoph Zwerschke wrote:
> Duncan Booth schrieb:
>> In Javascript Object properties (often used as an associative array)
>> are defined as unordered although as IE seems to always store them in
>> the order of original insertion it wouldn't surprise me if there are
>> a lot of websites depending
Christoph Zwerschke wrote:
> Fuzzyman wrote:
>
> > So what do you want returned when you ask for d1[1] ? The member keyed
> > by 1, or the item in position 1 ?
>
> In case of conflict, the ordered dictionary should behave like a
> dictionary, not like a list. So d1[1] should be the member keyed by
Ok.
That answers a question in the post I've just made. This thread is hard
to follow.
Thanks
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
--
http://mail.python.org/mailman/listinfo/python-list
Alex Martelli wrote:
> Fuzzyman <[EMAIL PROTECTED]> wrote:
>...
> > > - the internal keys list should be hidden
> >
> > I disagree. It is exposed so that you can manually change the order
> > (e.g. to create a "sorted" dict, rather than one ordered by key
> > insertion).
> >
> > What do you *g
Christoph Zwerschke <[EMAIL PROTECTED]> wrote:
...
> d.ksort() = d.sortkeys()
> d.asort() = d.sortvalues()
>
> d.sort() could default to one of them (not sure which one).
Define JUST d.sort, you can trivially implement the other as
d.sort(key=d.get).
Alex
--
http://mail.python.org/mailman/l
On Wed, 23 Nov 2005 23:39:22 +0100, Christoph Zwerschke wrote
> Carsten Haese schrieb:
>
> > Thus quoth the Zen of Python:
> > "Explicit is better than implicit."
> > "In the face of ambiguity, refuse the temptation to guess."
> >
> > With those in mind, since an odict behaves mostly like a dicti
Here is another old posting I just found which again gives the same use
cases and semantics:
http://mail.python.org/pipermail/python-dev/2005-March/051974.html
"Keys are iterated over in the order that they are added. Setting a
value using a key that compares equal to one already in the dict
rep
Carsten Haese schrieb:
> Thus quoth the Zen of Python:
> "Explicit is better than implicit."
> "In the face of ambiguity, refuse the temptation to guess."
>
> With those in mind, since an odict behaves mostly like a dictionary, []
> should always refer to keys. An odict implementation that wants
Fuzzyman wrote:
> That's not the only use case. Other use cases are to have a specific
> order, not based on entry time.
>
> Simple example :
> d1 = OrderedDict(some_dict.items())
> d1.sequence.sort()
> d1 is now an ordered dict with the keys in alphabetic order.
As I said, I would not need to a
Fuzzyman wrote:
>>- the internal keys list should be hidden
> I disagree. It is exposed so that you can manually change the order
> (e.g. to create a "sorted" dict, rather than one ordered by key
> insertion). What do you *gain* by hiding it ?
See my other posting. Of course hiding the list can
Fuzzyman wrote:
> So what do you want returned when you ask for d1[1] ? The member keyed
> by 1, or the item in position 1 ?
In case of conflict, the ordered dictionary should behave like a
dictionary, not like a list. So d1[1] should be the member keyed by 1,
not the item in position 1. Only i
>> I think it would be probably the best to hide the keys list from the
>> public, but to provide list methods for reordering them (sorting,
>> slicing etc.).
Tom Anderson wrote:
> I'm not too keen on this - there is conceptually a list here, even if
> it's one with unusual constraints, so the
Bengt Richter wrote:
> >>> from odictb import OrderedDict
> >>> d1 = OrderedDict([(1, 11), (2, 12), (3, 13)])
> >>> d1
> {1: 11, 2: 12, 3: 13}
> >>> d1[1:]
> {2: 12, 3: 13}
> >>> d1[0:1] + d1[2:3]
> {1: 11, 3: 13}
> >>> d1.reverse()
> >>> d1
> {3: 13, 2: 12, 1: 11}
> >>> d1.insert(1, (
Alex Martelli schrieb:
> I detest and abhor almost-sequences which can't be sliced (I consider
> that a defect of collections.deque). If the ordered dictionary records
> by its sequencing the time order of key insertion, being able to ask for
> "the last 5 keys entered" or "the first 3 keys enter
Ganesan Rajagopal wrote:
> the definition of "sorted" and "ordered", before we can > go on ? Sorted
> would be ordered by key comparison. Iterating over such a container will
> give you the keys in sorted order. Java calls this a SortedMap. See
> http://java.sun.com/j2se/1.4.2/docs/api/java/uti
Alex Martelli wrote:
> However, since Christoph himself just misclassified C++'s std::map as
> "ordered" (it would be "sorted" in this new terminology he's now
> introducing), it seems obvious that the terminological confusion is
> rife. Many requests and offers in the past for "ordered dictionar
On Wed, 2005-11-23 at 15:17, Christoph Zwerschke wrote:
> Bengt Richter wrote:
> > I think the concept has converged to a replace-or-append-by-key ordering
> > of key:value items with methods approximately like a dict. We're now
> > into usability aspects such as syntactic sugar vs essential pri
Duncan Booth schrieb:
> In Javascript Object properties (often used as an associative array) are
> defined as unordered although as IE seems to always store them in the order
> of original insertion it wouldn't surprise me if there are a lot of
> websites depending on that behaviour.
You're rig
>>* C++ has a Map template in the STL which is ordered (a "Sorted
>>Associative Container").
Alex Martelli wrote:
> Ordered *by comparisons on keys*, NOT by order of insertion -- an
> utterly and completely different idea.
Shame on me. I talked so much about the difference between "ordered" and
Bengt Richter wrote:
> I think the concept has converged to a replace-or-append-by-key ordering
> of key:value items with methods approximately like a dict. We're now
> into usability aspects such as syntactic sugar vs essential primitives,
> and default behaviour vs selectable modes, ISTM.
Ye
[EMAIL PROTECTED] schrieb:
> It seems to be though as "ordered dictionary" are slowly to be confined
> to only "ordered on order of change to the dictionary".
"Ordered dictionary" means that the keys are not an ordinary set like in
an ordinary dictionary, but an "ordered set." I think this defini
Steve Holden schrieb:
> Perhaps now the answer top your question is more obvious: there is by no
> means universal agreement on what an "ordered dictionary" should do.
> Given the ease with which Python allows you to implement your chosen
> functionality it would be presumptuous of the core deve
Fuzzyman <[EMAIL PROTECTED]> wrote:
> There is already an update method of course. :-)
>
> Slicing an ordered dictionary is interesting - but how many people are
> actually going to use it ? (What's your use case)
I detest and abhor almost-sequences which can't be sliced (I consider
that a defec
Fuzzyman <[EMAIL PROTECTED]> wrote:
...
> > - the internal keys list should be hidden
>
> I disagree. It is exposed so that you can manually change the order
> (e.g. to create a "sorted" dict, rather than one ordered by key
> insertion).
>
> What do you *gain* by hiding it ?
Freedom of implem
Rick Wotnaz wrote:
> "Fuzzyman" <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
> >
> > Christoph Zwerschke wrote:
> >> - the internal keys list should be hidden
> >
> > I disagree. It is exposed so that you can manually change the
> > order (e.g. to create a "sorted" dict, rather than on
On Tue, 2005-11-22 at 20:44, Tom Anderson wrote:
> On Tue, 22 Nov 2005, Carsten Haese wrote:
>
> > On Tue, 2005-11-22 at 14:37, Christoph Zwerschke wrote:
> >
> >> In Foord/Larosa's odict, the keys are exposed as a public member which
> >> also seems to be a bad idea ("If you alter the sequence l
Ganesan Rajagopal wrote:
>> [EMAIL PROTECTED] com <[EMAIL PROTECTED]> writes: > what would be
>
> the definition of "sorted" and "ordered", before we can > go on ? Sorted
> would be ordered by key comparison. Iterating over such a container will
> give you the keys in sorted order. Java ca
"Fuzzyman" <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
>
> Christoph Zwerschke wrote:
>> - the internal keys list should be hidden
>
> I disagree. It is exposed so that you can manually change the
> order (e.g. to create a "sorted" dict, rather than one ordered
> by key insertion).
>
On 23 Nov 2005 01:24:46 -0800, "Kay Schluehr" <[EMAIL PROTECTED]> wrote:
>
>[EMAIL PROTECTED] wrote:
>> Steve Holden wrote:
>> > Perhaps now the answer top your question is more obvious: there is by no
>> > means universal agreement on what an "ordered dictionary" should do.
>> > Given the ease wi
Christoph Zwerschke wrote:
> Ok, I just did a little research an compared support for ordered dicts
> in some other languages:
>
Just to add to your list:
In Javascript Object properties (often used as an associative array) are
defined as unordered although as IE seems to always store them in
[EMAIL PROTECTED] wrote:
> Steve Holden wrote:
> > Perhaps now the answer top your question is more obvious: there is by no
> > means universal agreement on what an "ordered dictionary" should do.
> > Given the ease with which Python allows you to implement your chosen
> > functionality it would b
While we're on the subject, it would be useful to be able to paste in a
changelog as well as a description.
Currently when updating versions you have to include the changelog in
the description - or not at all...
All the best,
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
--
http://m
There is already an update method of course. :-)
Slicing an ordered dictionary is interesting - but how many people are
actually going to use it ? (What's your use case)
You can already slice the sequence atribute and iterate over that.
All the best,
Fuzzyman
http://www.voidspace.org.uk/python
Christoph Zwerschke wrote:
> One implementation detail that I think needs further consideration is in
> which way to expose the keys and to mix in list methods for ordered
> dictionaries.
>
> In http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/107747
> the keys are exposed via the keys() me
Steve Holden wrote:
> Perhaps now the answer top your question is more obvious: there is by no
> means universal agreement on what an "ordered dictionary" should do.
> Given the ease with which Python allows you to implement your chosen
> functionality it would be presumptuous of the core develope
Bengt Richter wrote:
> On 22 Nov 2005 02:16:22 -0800, "Fuzzyman" <[EMAIL PROTECTED]> wrote:
>
> >
> >Kay Schluehr wrote:
> >> Christoph Zwerschke wrote:
> >>
> >> > That would be also biased (in favour of Python) by the fact that
> >> > probably very little people would look for and use the packag
Christoph Zwerschke wrote:
> >>I still believe that the concept of an "ordered dictionary" ("behave
> >>like dict, only keep the order of the keys") is intuitive and doesn't
> >>give you so much scope for ambiguity. But probably I need to work on an
> >>implementation to become more clear about po
Christoph Zwerschke wrote:
> This is probably a FAQ, but I dare to ask it nevertheless since I
> haven't found a satisfying answer yet: Why isn't there an "ordered
> dictionary" class at least in the standard list? Time and again I am
> missing that feature. Maybe there is something wrong with m
Alex Martelli wrote:
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>...
> > But I can also record these changes in a seperate table which then
> > becomes a "sorted" case ?
>
> somedict['x']='y', per se, does no magic callback to let you record
> anything when type(somedict) is dict. You can
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
...
> But I can also record these changes in a seperate table which then
> becomes a "sorted" case ?
somedict['x']='y', per se, does no magic callback to let you record
anything when type(somedict) is dict. You can wrap or subclass to your
heart's c
Alex Martelli wrote:
> What you can obtain (or anyway easily simulate in terms of effects on a
> loop) through an explicit call to the 'sorted' built-in, possibly with a
> suitable 'key=' parameter, I would call "sorted" -- exactly because, as
> Bengt put it, there IS a sorting algorithm which, et
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Bengt Richter wrote:
> > For me the implication of "sorted" is that there is a sorting algorithm
> > that can be used to create an ordering from a prior state of order,
> > whereas "ordered" could be the result of arbitrary permutation, e.g.,
> > manu
> Alex Martelli <[EMAIL PROTECTED]> writes: > Ordered
*by order of key insertion*: Java, PHP > Ordered *by other
criteria*: LISP, C++ Java supports both ordered by key insertion
(LinkedHashMap) as well as ordered by key comparison (TreeMap).
Ganesan
--
Ganesan Rajagopal (rganesan at
> [EMAIL PROTECTED] com <[EMAIL PROTECTED]> writes: > what would be
the definition of "sorted" and "ordered", before we can > go on ?
Sorted would be ordered by key comparison. Iterating over such a
container will give you the keys in sorted order. Java calls this
a SortedMap. See
http://
Bengt Richter wrote:
> For me the implication of "sorted" is that there is a sorting algorithm
> that can be used to create an ordering from a prior state of order,
> whereas "ordered" could be the result of arbitrary permutation, e.g.,
> manual shuffling, etc. Of course either way, a result can b
On 22 Nov 2005 19:15:42 -0800, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
>Alex Martelli wrote:
>> However, since Christoph himself just misclassified C++'s std::map as
>> "ordered" (it would be "sorted" in this new terminology he's now
>> introducing), it seems obvious that the terminologic
Alex Martelli wrote:
> However, since Christoph himself just misclassified C++'s std::map as
> "ordered" (it would be "sorted" in this new terminology he's now
> introducing), it seems obvious that the terminological confusion is
> rife. Many requests and offers in the past for "ordered dictionar
Tom Anderson <[EMAIL PROTECTED]> wrote:
...
> > have a certain order that is preserved). Those who suggested that the
> > "sorted" function would be helpful probably thought of a "sorted
> > dictionary" rather than an "ordered dictionary."
>
> Exactly.
>
> Python could also do with a sorted d
On Tue, 22 Nov 2005 22:06:12 +0100, Christoph Zwerschke <[EMAIL PROTECTED]>
wrote:
>> d1[0:0] + d1[2:2] ==> OrderedDict( (1, 11), (3, 13) )
>
>Oops, sorry, that was nonsense again. I meant
>d1[0:1] + d1[1:2] ==> OrderedDict( (1, 11), (3, 13) )
>
>> Ordered dictionaries could allow slicing and con
Christoph Zwerschke <[EMAIL PROTECTED]> wrote:
...
> * C++ has a Map template in the STL which is ordered (a "Sorted
> Associative Container").
Ordered *by comparisons on keys*, NOT by order of insertion -- an
utterly and completely different idea.
> So ordered dictionaries don't seem to be s
On Tue, 22 Nov 2005, Christoph Zwerschke wrote:
> Fuzzyman schrieb:
>
>> Of course ours is ordered *and* orderable ! You can explicitly alter
>> the sequence attribute to change the ordering.
>
> What I actually wanted to say is that there may be a confusion between a
> "sorted dictionary" (one
On Tue, 22 Nov 2005, Christoph Zwerschke wrote:
> One implementation detail that I think needs further consideration is in
> which way to expose the keys and to mix in list methods for ordered
> dictionaries.
>
> In Foord/Larosa's odict, the keys are exposed as a public member which
> also seem
On Tue, 22 Nov 2005 20:37:40 +0100, Christoph Zwerschke <[EMAIL PROTECTED]>
wrote:
>One implementation detail that I think needs further consideration is in
>which way to expose the keys and to mix in list methods for ordered
>dictionaries.
>
>In http://aspn.activestate.com/ASPN/Cookbook/Python
On Tue, 22 Nov 2005, Carsten Haese wrote:
> On Tue, 2005-11-22 at 14:37, Christoph Zwerschke wrote:
>
>> In Foord/Larosa's odict, the keys are exposed as a public member which
>> also seems to be a bad idea ("If you alter the sequence list so that it
>> no longer reflects the contents of the dic
Bengt Richter wrote:
> On 22 Nov 2005 03:07:47 -0800, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> >
> >Bengt Richter wrote:
> >> Ok, so if not in the standard library, what is the problem? Can't find what
> >> you want with google and PyPI etc.? Or haven't really settled on what your
> >> _
On 22 Nov 2005 11:18:19 -0800, "Kay Schluehr" <[EMAIL PROTECTED]> wrote:
>Bengt Richter wrote:
>> On Mon, 21 Nov 2005 01:27:22 +0100, Christoph Zwerschke <[EMAIL PROTECTED]>
>> wrote:
>
>> Note that is isn't hard to snap a few pieces together to make an ordered
>> dict to your own specs. But IMO
On Tue, 22 Nov 2005 20:15:18 +0100, Christoph Zwerschke <[EMAIL PROTECTED]>
wrote:
> >>def __init__(self, init_val = ()):
> >> dict.__init__(self, init_val)
> >> self.sequence = [x[0] for x in init_val]
>
>Fuzzyman wrote:
>
> > But that doesn't allow you to create an ordered dict from ano
On Tue, 22 Nov 2005 21:24:29 +0100, Christoph Zwerschke <[EMAIL PROTECTED]>
wrote:
>Carsten Haese wrote:
>
>> That could easily be fixed by making the sequence a "managed property"
>> whose setter raises a ValueError if you try to set it to something
>> that's not a permutation of what it was.
>
> d1[0:0] + d1[2:2] ==> OrderedDict( (1, 11), (3, 13) )
Oops, sorry, that was nonsense again. I meant
d1[0:1] + d1[1:2] ==> OrderedDict( (1, 11), (3, 13) )
> Ordered dictionaries could allow slicing and concatenation.
Some operations such as concatenation need of course special
considerations,
1 - 100 of 191 matches
Mail list logo
