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 parameters
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
--
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, etc.
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
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 default configuration
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 that any key
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
--
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
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 which case
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 of
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
Bengt Richter schrieb:
OTOH,
{}[:]
Traceback (most recent call last):
File stdin, 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 permitting
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 sequence of
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] when
key is an
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 this
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
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 be sliced (I
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
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 either.
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
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.
Speaking
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 use
case is
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 i can
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:
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
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
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 really
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 *gain* by hiding it ?
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
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 1,
not
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 on that
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 an odict behaves mostly
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]
--
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
--
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
--
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 public
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, not like a
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.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
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 already
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()
*but*
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
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
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]
Private email: [EMAIL
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 my
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 possible hidden
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 package in the
cheese shop
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 developers to
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() method
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
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
--
[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 be
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
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 with which Python
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).
What do you
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 calls this a
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 list so that
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 one ordered
by key
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 implementation,
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 defect of
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
[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 definition is
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.
Yes,
* 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
sorted
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 right
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
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 dictionaries
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
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 entered
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, (4,14))
d1
{3: 13, 4: 14, 2:
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 there
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 in
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 only
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 access
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 to allow
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
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 dictionary, []
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
--
Tom Anderson wrote:
Incidentally, can we call that the Larosa-Foord ordered mapping?
The implementation, sure.
Then it sounds like some kind of rocket science discrete mathematics stuff
But math folks usually name things after the person(s) who came
up with the idea, not just some random
Alex Martelli schrieb:
Perl hashes now keep track of 'order of keys'? That's new to me, they
sure didn't back when I used Perl!
Maybe I shouldn't have talked about Perl when I'm an ignoramus about
that language... You're right, Perl has unordered arrays. That was new
to me since I associate
.
What I don't understand is why legitimate questions such as why are
there no ordered dictionaries are immediately interpreted as
*complaints* and not just as questions. If I ask such a question, I am
not complaining but trying to simply figure out *why* there is no such
thing. Probably
Alex Martelli wrote:
What about PHP? Thanks!
according to some random PHP documentation I found on the intarweb:
An array in PHP is actually an ordered map. A map is a type that
maps values to keys.
and later:
A key may be either an integer or a string. If a key is the standard
Bengt Richter wrote:
d = OrderedDict(); d[1]='one'; d[2]='two' = list(d) = [1, 2]
ok, now we do d[1]='ein' and what is the order? list(d) = [2, 1] ??
Or do replacements not count as insertions?
If you simply set a value for a key that already exists, the order
should not be changed. I
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 package in the
cheese shop if they were looking for ordered dicts.
Does anyone actually use this site? While the Vaults offered a nice
place and a
Christoph Zwerschke wrote:
Fredrik Lundh wrote:
[snip..]
You're right; I found creating a Larosa/Foord OrderedDict in this
example to be even 8 times slower than an ordinary dict. However, two
things need to be said here: 1) The dictionary in my exmaple was pretty
small (only 3 items), so you
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 package in the
cheese shop if they were looking for ordered dicts.
Does anyone actually use this site? While the Vaults
On Tue, 22 Nov 2005 09:20:34 +0100, Fredrik Lundh wrote:
Tom Anderson wrote:
Incidentally, can we call that the Larosa-Foord ordered mapping?
The implementation, sure.
Then it sounds like some kind of rocket science discrete mathematics stuff
But math folks usually name things after
Christoph Zwerschke wrote:
But please see my other reply: If the dictionary has more than 3 items
(say 10 or 20), and an effective ordered dict is used, it's not really
a lot slower. At least if we are talking about a situation were on
demand is always. So, on the other side there isn't
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
_requirements_ are? That seems to be the primary problem people who complain
with why no sprollificator mode? questions.
no sprollificator mode? questions.
What I don't understand is why legitimate questions such as why are
there no ordered dictionaries are immediately interpreted as
*complaints* and not just as questions. If I ask such a question, I am
not complaining but trying to simply figure out *why
Christoph Zwerschke wrote:
Fredrik Lundh wrote:
I'll repeat this one last time: for the use cases presented by Zwerschke
and bonono, using a list as the master data structure, and creating the
dictionary on demand, is a lot faster than using a ready-made ordered
dict implementation. if
On 22 Nov 2005 01:41:44 -0800,
Kay Schluehr [EMAIL PROTECTED] wrote:
Does anyone actually use this site? While the Vaults offered a nice
place and a nice interface the Cheese Shop has the appeal of a code
slum.
Looking at the Cheese Shop's home page at
A.M. Kuchling wrote:
On 22 Nov 2005 01:41:44 -0800,
Kay Schluehr [EMAIL PROTECTED] wrote:
Does anyone actually use this site? While the Vaults offered a nice
place and a nice interface the Cheese Shop has the appeal of a code
slum.
Looking at the Cheese Shop's home page at
Of course ours is ordered *and* orderable ! You can explicitly alter
the sequence attribute to change the ordering.
I think we're looking at improving performance based on some of the
suggestions here - as well as possibly widening it to include some of
the alternative use cases. (Or at least
Fredrik Lundh [EMAIL PROTECTED] wrote:
...
But math folks usually name things after the person(s) who came
up with the idea, not just some random implementer. The idea of
Wrong: you're forgetting Stigler's Law of Misonomy (which I imagine must
have NOT been discovered by Stigler...;-). The
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.
Sure. Others think so too. The problem is that if you and these other
people actually write
Christoph Zwerschke [EMAIL PROTECTED] wrote:
Alex Martelli schrieb:
Perl hashes now keep track of 'order of keys'? That's new to me, they
sure didn't back when I used Perl!
Maybe I shouldn't have talked about Perl when I'm an ignoramus about
that language... You're right, Perl has
A.M. Kuchling [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
[...]
What would improve the Cheese Shop's interface for you?
Getting rid of those damn top level links to old versions.
Seeing a long list of old versions, when 99% of visitors are
only interested in the current version,
Christoph Zwerschke wrote:
But of course, it will always be slower since it is constructed on top
of the built-in dict. In end effect, you always have to maintain a
sequence *plus* a dictionary, which will be always slower than a sheer
dictionary. The ordered dictionary class just hides this
1 - 100 of 191 matches
Mail list logo
