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 think it is generally useful.
I fully agree with the following posting where somebody complains why so
very basic and useful things are not part of the standard library: http://groups.google.com/group/comp....52d2f771a49857
Are there plans to get it into the standard lib sometime?
-- Christoph
Nov 22 '05
210  10440 
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', 'varchar'),
'sal': ('Salary', 'float') }
Now if I want these things to be presented in this order, I need to run
through a separate list ('pid', 'name', 'sal') that holds the order.
Ok, you could simply use a list instead of a dictionary:
d = ( ('pid', 'Employee ID', 'int'),
('name', 'Employee name', 'varchar'),
('sal', 'Salary', 'float') )
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
for key, (name, type) in d:
print key, name, type # e.g. generate form entry
This works as long as you *only* have to go through the list
sequentially. But maybe you want to print the name with its description
at some other place as well. Now how do you access its description
'Employee name' so easily?
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
either...
</F>
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
either...
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.
Of course there are more than one way to skin a cat(well it may be
against the general idiom of python) but in some situation certain way
is preferred.
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
either...
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.
Of course there are more than one way to skin a cat(well it may be
against the general idiom of python) but in some situation certain way
is preferred.
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 need it:
index = dict(d)
That's exactly the kind of things I find myself doing too often and what
I was talking about : You are using *two* pretty redundant data
structures, a dictionary and a list/tuple to describe the same thing.
Ok, you can use a trick to automatically create the dictionary from the
tuple, but still it feels somewhat "unnatural" for me. A "ordered
dictionary" would be the more "natural" data structure here.
I also wanted to mention the uglyness in the definition (nested tuples),
but then I understood that even an ordered dictionary would not
eliminate that uglyness, since the curly braces are part of the Python
syntax and cannot be used for creating ordered dictionaries anyway. I
would have to define the ordered dictionary in the very same ugly way:
d = odict(('pid', ('Employee ID', 'int')),
('name', ('Employee name', 'varchar')),
('sal', ('Salary', 'float')))
(Unless the Python syntax would be extend to use double curly braces or
something for ordered dictionaries - but I understand that this is not
an option.)
-- Christoph
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 need it:
index = dict(d)
That's exactly the kind of things I find myself doing too often and what
I was talking about : You are using *two* pretty redundant data
structures, a dictionary and a list/tuple to describe the same thing.
Ok, you can use a trick to automatically create the dictionary from the
tuple, but still it feels somewhat "unnatural" for me. A "ordered
dictionary" would be the more "natural" data structure here.
I also wanted to mention the uglyness in the definition (nested tuples),
but then I understood that even an ordered dictionary would not
eliminate that uglyness, since the curly braces are part of the Python
syntax and cannot be used for creating ordered dictionaries anyway. I
would have to define the ordered dictionary in the very same ugly way:
d = odict(('pid', ('Employee ID', 'int')),
('name', ('Employee name', 'varchar')),
('sal', ('Salary', 'float')))
(Unless the Python syntax would be extend to use double curly braces or
something for ordered dictionaries - but I understand that this is not
an option.)
-- Christoph
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 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.
What I think is better is like the itertools recipe of giving example
of how one can make their own based on the needs.
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 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.
What I think is better is like the itertools recipe of giving example
of how one can make their own based on the 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 shaken out to show a clearly superior
version? Is any version sufficiently beneficial to write a PEP for its
inclusion in the standard library?
At least it shows I'm not the only one who thinks ordered dictionaries
may be sometimes nice to have.
I simply wanted to ask why it is not available in the standard lib,
since I simply don't know
- has it not been demanded loud enough?
Loud demands don't count for much. PEPs with popular working
implementations do.
Sorry, I did not mean "loud enough" but "often enough". The same what
you are calling "popular."
- because nobody presented a satisfying implementation yet?
I'm not sure what you mean by "satisfying ".
You can take your own definition: "sufficient ly shaken out", "working",
"popular", and "succifient ly beneficial" and "proven (to the BDFL's
criteria)".
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 according to
some criteria which cannot be derived from the keys themselves."
-- Christoph
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 shaken out to show a clearly superior
version? Is any version sufficiently beneficial to write a PEP for its
inclusion in the standard library?
At least it shows I'm not the only one who thinks ordered dictionaries
may be sometimes nice to have.
I simply wanted to ask why it is not available in the standard lib,
since I simply don't know
- has it not been demanded loud enough?
Loud demands don't count for much. PEPs with popular working
implementations do.
Sorry, I did not mean "loud enough" but "often enough". The same what
you are calling "popular."
- because nobody presented a satisfying implementation yet?
I'm not sure what you mean by "satisfying ".
You can take your own definition: "sufficient ly shaken out", "working",
"popular", and "succifient ly beneficial" and "proven (to the BDFL's
criteria)".
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 according to
some criteria which cannot be derived from the keys themselves."
-- Christoph bo****@gmail.co m 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 because I believed it is
pretty unabmiguous what an "ordered dictionary" is and how it should
behave. That's why I asked myself why something that straigthforward has
not been added to the standard lib yet. Maybe I'm wrong; I must admit
that I haven't meditated about it very much.
Do you have an example for different options of behavior?
-- Christoph This thread has been closed and replies have been disabled. Please start a new discussion. |
