Stuart McGraw wrote
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, is just visual noise,
and really lame. Move the old
Fredrik Lundh wrote:
Ben Sizer wrote:
This is interesting; I would have thought that the tuple is read and a
dictionary created by inserting each pair sequentially. Is this not the
case?
pointers to the members of each pair, yes. but a pointer copy is a
cheap operation (for the given
Fredrik Lundh [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Stuart McGraw wrote
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
to be the primary problem people who complain
with why 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
Stuart McGraw wrote:
Hmm, so two versions means one is a development version,
and the other is a stable version? I did not know that, and did
not see it documented on the site. I would say documenting
that would be an interface improvement.
well, that's up to the developer. when you
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
_requirements_ are? That seems to be the
On Tue, 22 Nov 2005 10:26:22 +0100, Christoph Zwerschke [EMAIL PROTECTED]
wrote:
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
Alex Martelli wrote:
Perl's _arrays_ are a bit like Python _lists_, and ordered; it's the
_hashes_ that are a bit like Python _dicts_, and unordered. PHP's use
of array for both concepts may indeed be a bit confusing.
Perl's _hashes_ have been also called _associative arrays_ originally.
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 where the keys are automatically sorted) and an
ordered
Bengt Richter wrote:
I'm mostly friendly ;-)
I'm pretty sure you are :-)
-- Chris
--
http://mail.python.org/mailman/listinfo/python-list
Bengt Richter wrote:
After finally reading that the odict.py in PyPI by Larosa/Foord was what was
desired,
but slower in use than what Fredrik posted, I decided to see if I could speed
up odict.py.
I now have a version that I think may be generally faster.
Hm, I wouldn't formulate it that
On Tue, 2005-11-22 at 13:37, Christoph Zwerschke wrote:
Would the default semantics below really be that suprising?
An ordered dictionary remembers the order in which keys are first seen
[...] Overwriting an entry replaces
its value, but does not affect its position in the key order.
Bengt Richter wrote:
On Mon, 21 Nov 2005 01:27:22 +0100, Christoph Zwerschke [EMAIL PROTECTED]
wrote:
Fredrik Lundh wrote:
if you restructure the list somewhat
d = (
('pid', ('Employee ID', 'int')),
('name', ('Employee name', 'varchar')),
('sal',
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 which is bad. It should be a
Magnus Lycka schrieb:
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
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 another
ordered dict.
Right; I did not want to present a full implementation, just the
relevant
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 dictionary, you have broken your
OrderedDict).
That
Carsten Haese schrieb:
I don't think it's intuitive if you can't describe it without
contradicting yourself. If the order of the keys really were the order
in which they were first seen by the dictionary, deleting and recreating
a key should maintain its original position.
Admitted that
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.
Ok, a managed attribute would be an option. You would allow people to do
what they want with
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 subtleties.
Bengt Richter
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,
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.
Ok, a
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 another
ordered
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 it belongs in
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
_requirements_ are?
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 dictionary,
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
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 seems to
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 where the
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 such an
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 concatenation.
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 dict, like binary
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
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 terminological confusion is
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 be said
[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
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] [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.,
manual shuffling,
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, etc,
[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
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 wrap or
Fredrik Lundh wrote:
[EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
but you can easily generate an index when you need it:
index = dict(d)
name, type = index[pid]
print name
the index should take less than a microsecond to create, and since it
points to
[EMAIL PROTECTED] wrote:
If I need the dict feature 90% of the time, and the list feature 10% of
the time.
Wasn't your use case that you wanted to specify form fields in
a given order (LIST), render a default view of the form in that
order (LIST), and, later on, access the field specifiers in
Fredrik Lundh wrote:
[EMAIL PROTECTED] wrote:
If I need the dict feature 90% of the time, and the list feature 10% of
the time.
Wasn't your use case that you wanted to specify form fields in
a given order (LIST), render a default view of the form in that
order (LIST), and, later on,
Op 2005-11-21, Christoph Zwerschke schreef [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote:
Personally, I have needs for ordered dict but I don't think it should
be in standard library though, as different situation called for
different behaviour for ordered and skewing my code to a standard lib
Fredrik Lundh wrote:
[EMAIL PROTECTED] wrote:
Using the same logic, we don't need types other than string in a DBMS
as we can always convert a string field into some other types when it
is needed.
No, that's not the same logic. The dict() in my example doesn't convert be-
tween data
Ben Sizer wrote:
No, that's not the same logic. The dict() in my example doesn't convert be-
tween data types; it provides a new way to view an existing data structure.
This is interesting; I would have thought that the tuple is read and a
dictionary created by inserting each pair
Fredrik Lundh wrote:
Ben Sizer wrote:
No, that's not the same logic. The dict() in my example doesn't convert
be-
tween data types; it provides a new way to view an existing data
structure.
This is interesting; I would have thought that the tuple is read and a
dictionary
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
...
d = somedict_from_db()
prefer=['f','a',b']
def my_order(d):
for x in prefer:
if x in d: yield x
s = frozenset(prefer)
for x in d:
if x not in s: yield x
Yes, a much cleaner architecture (if you don't need any sorting
Fuzzyman wrote:
[snip..]
(as an example, on my machine, using Foord's OrderedDict class
on Zwerschke's example, creating the dictionary in the first place
takes 5 times longer than the index approach, and accessing an
item takes 3 times longer. you can in fact recreate the index 6
Ben Finney wrote:
Another possibility: ordered dictionaries are not needed when Python
2.4 has the 'sorted' builtin.
Christoph Zwerschke wrote:
The 'sorted' function does not help in the case I have indicated,
where I do not want the keys to be sorted alphabetically, but
according to
Fredrik Lundh wrote:
(as an example, on my machine, using Foord's OrderedDict class
on Zwerschke's example, creating the dictionary in the first place
takes 5 times longer than the index approach, and accessing an
item takes 3 times longer. you can in fact recreate the index 6
times before
Fredrik Lundh [EMAIL PROTECTED] wrote:
...
(but assume that I have some other use case isn't a valid use
case)
+1 QOTW
Alex
--
http://mail.python.org/mailman/listinfo/python-list
Alex Martelli wrote:
Note the plural in 'insertion orderS': some people care about the FIRST
time a key was added to a dict, some about the LAST time it was added,
some about the latest time it was 'first inserted' (added and wasn't
already there) as long as it's never been deleted since that
In article [EMAIL PROTECTED],
Alex Martelli [EMAIL PROTECTED] wrote:
I think you're wrong here. People in the past who have requested or
implemented stuff they called 'ordered dicts' in the past had in mind
drastically different things, based on some combination of insertion
orders, keys, and
On Sun, 20 Nov 2005, Alex Martelli wrote:
Christoph Zwerschke [EMAIL PROTECTED] wrote:
The 'sorted' function does not help in the case I have indicated, where
I do not want the keys to be sorted alphabetically, but according to
some criteria which cannot be derived from the keys
Fredrik Lundh wrote:
huh? if you want a list, use a list.
d = [('a', {...}), ('b', {})]
If one wants uniform access to a nested data structure like this one
usually starts writing a wrapper class. I do not think the requirement
is anyhow deeper than a standard wrapper around such a
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 you will access things via the
On 20 Nov 2005 21:12:52 -0800, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Bengt Richter wrote:
On Sun, 20 Nov 2005 22:03:34 +0100, Christoph Zwerschke [EMAIL PROTECTED]
wrote:
Ordering the keys isn't the normal case, and can be done easily when
needed.
That depends. Maybe I do not want
On Mon, 21 Nov 2005 01:27:22 +0100, Christoph Zwerschke [EMAIL PROTECTED]
wrote:
Fredrik Lundh wrote:
if you restructure the list somewhat
d = (
('pid', ('Employee ID', 'int')),
('name', ('Employee name', 'varchar')),
('sal', ('Salary', 'float'))
)
you
On 21 Nov 2005 01:54:38 -0800, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
[EMAIL PROTECTED] wrote:
If I need the dict feature 90% of the time, and the list feature 10% of
the time.
Wasn't your use case that you wanted to specify form fields in
a given order (LIST),
Christoph Zwerschke [EMAIL PROTECTED] wrote:
...
But I think the following rule is natural enough to consider it as THE
standard behavior of ordered dictionaries:
Insertion: If the key exists: Don't change the order. If it does not
exist: Append it to the sequence of keys. Deletion:
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 programming
style, but I rather
Christoph Zwerschke [EMAIL PROTECTED] 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?
What answers have you received that have not been satisfactory?
Uzytkownik Christoph Zwerschke [EMAIL PROTECTED] napisal w wiadomosci
news:[EMAIL PROTECTED]
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
przemek drochomirecki wrote:
i am not sure what is the purpose of having ordered dictionaries built in
python, could u provide any examples?
i use a contruction:
for x in sorted(d.keys())
By ordered dict, one usually wants order that is arbitary which cannot
be derived from the content,
[EMAIL PROTECTED] wrote:
I am writing a web applications(simple forms) which has a number of
fields. Each field naturally has a name and a number of
attributes(formatting etc.), like this :
d = {'a':{...}, 'b':{}}
This dict would be passed to the Kid template system which would lay it
Fredrik Lundh wrote:
[EMAIL PROTECTED] wrote:
I am writing a web applications(simple forms) which has a number of
fields. Each field naturally has a name and a number of
attributes(formatting etc.), like this :
d = {'a':{...}, 'b':{}}
This dict would be passed to the Kid
You asked why not rather than has anyone done this anyway; if
you asked the latter of the Python Cookbook, you might find something
like this:
URL:http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/107747
A little old, and pre-dates subclassable native types, but quite
What answers have you received that have not been satisfactory?
I googled a little bit and haven't found many answers at all. Some were
in the posting I mentioned: Stuff should go into the standard lib only
when it is mature and right enough. However, we are already at Python
2.4 and there is
[EMAIL PROTECTED] schrieb:
By ordered dict, one usually wants order that is arbitary which cannot
be derived from the content, say insertion order(most ordered dict I
saw use this order).
I am writing a web applications(simple forms) which has a number of
fields. Each field naturally has a
[restored my attribution line so we know who said what]
Christoph Zwerschke [EMAIL PROTECTED] wrote:
Ben Finney wrote:
In what cases do you find yourself needing a dict that preserves
its key order? Can you present a use case that would be improved
by an ordered dict?
There are too many
Christoph Zwerschke wrote:
The example above is a bit misleading, because using 'a', 'b' as keys
can give the impression that you just have to sort() the keys to have
what you want. So let's make it more realistic:
d = { 'pid': ('Employee ID', 'int'),
'name': ('Employee name',
Fredrik Lundh wrote:
but you can easily generate an index when you need it:
index = dict(d)
name, type = index[pid]
print name
the index should take less than a microsecond to create, and since it
points to the members of the original dict, it doesn't use much memory
Fredrik Lundh wrote:
if you restructure the list somewhat
d = (
('pid', ('Employee ID', 'int')),
('name', ('Employee name', 'varchar')),
('sal', ('Salary', 'float'))
)
you can still loop over the list
...
but you can easily generate an index when you
Ben Finney wrote:
Another possibility: ordered dictionaries are not needed when Python
2.4 has the 'sorted' builtin.
What does sorted() have anythng to do with orders like insertion order,
or some arbitary order that instead of a,b,c,d,e, I want it as e, c, b,
d, a ?
Personally, I have needs
Ben Finney wrote:
Without an example, it's hard to know what you want to do and whether
an ordered dictionary is the best way to do it.
I have indicated an example, discussed in more detail in another subthread.
There are already enough competing implementations.
Have they been sufficiently
Christoph Zwerschke wrote:
[EMAIL PROTECTED] wrote:
Personally, I have needs for ordered dict but I don't think it should
be in standard library though, as different situation called for
different behaviour for ordered and skewing my code to a standard lib
way is no good.
I have
[EMAIL PROTECTED] wrote:
Personally, I have needs for ordered dict but I don't think it should
be in standard library though, as different situation called for
different behaviour for ordered and skewing my code to a standard lib
way is no good.
I have started the thread in the first place
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
...
there are at least two behaviour. What I need is a preferred order.
Say if I have designed a web form(correspond to a database table), I
just want say 3 fields that goes before anything else in the
presentation. The rest I don't care as the DBA
Christoph Zwerschke [EMAIL PROTECTED] wrote:
...
I have started the thread in the first place because I believed it is
pretty unabmiguous what an ordered dictionary is and how it should
I think you're wrong here. People in the past who have requested or
implemented stuff they called
Christoph Zwerschke [EMAIL PROTECTED] wrote:
...
The 'sorted' function does not help in the case I have indicated, where
I do not want the keys to be sorted alphabetically, but according to
some criteria which cannot be derived from the keys themselves.
Ah, but WHAT 'some criteria'?
Christoph Zwerschke [EMAIL PROTECTED] writes:
Ben Finney wrote:
Another possibility: ordered dictionaries are not needed when Python
2.4 has the 'sorted' builtin.
The 'sorted' function does not help in the case I have indicated,
where I do not want the keys to be sorted alphabetically, but
Alex Martelli wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
...
there are at least two behaviour. What I need is a preferred order.
Say if I have designed a web form(correspond to a database table), I
just want say 3 fields that goes before anything else in the
presentation. The
[EMAIL PROTECTED] wrote:
Using the same logic, we don't need types other than string in a DBMS
as we can always convert a string field into some other types when it
is needed.
You mean, like SQLite does? (http://www.sqlite.org/datatypes.html)
-Peter
--
Peter Hansen wrote:
[EMAIL PROTECTED] wrote:
Using the same logic, we don't need types other than string in a DBMS
as we can always convert a string field into some other types when it
is needed.
You mean, like SQLite does? (http://www.sqlite.org/datatypes.html)
Yup, they are using
On Sun, 20 Nov 2005 22:03:34 +0100, Christoph Zwerschke [EMAIL PROTECTED]
wrote:
Ordering the keys isn't the normal case, and can be done easily when
needed.
That depends. Maybe I do not want the keys to be sorted alphabetically,
but according to some criteria which cannot be derived from the
Bengt Richter wrote:
On Sun, 20 Nov 2005 22:03:34 +0100, Christoph Zwerschke [EMAIL PROTECTED]
wrote:
Ordering the keys isn't the normal case, and can be done easily when
needed.
That depends. Maybe I do not want the keys to be sorted alphabetically,
but according to some criteria
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
[sort by] some other metadata that is not present in the data.
[...]
Of course, you may say, just put another column that represent
this(some reporting programs I have seen do it this way) and that is
an option but not the only option.
It's a pretty
Ben Finney wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
[sort by] some other metadata that is not present in the data.
[...]
Of course, you may say, just put another column that represent
this(some reporting programs I have seen do it this way) and that is
an option but not the
[EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
but you can easily generate an index when you need it:
index = dict(d)
name, type = index[pid]
print name
the index should take less than a microsecond to create, and since it
points to the members of the original dict,
101 - 191 of 191 matches
Mail list logo
