On 2006-07-01, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
There's a few good reasons.
1 - golden handcuffs. Breaking old code is bad 90% of the time
2 - creating a set MAY be slower.
Python's sets seem to imply to that they will always be a hash map. in
this case, some creative hash map
Paddy [EMAIL PROTECTED] (P) wrote:
P [EMAIL PROTECTED] wrote:
This has been bothering me for a while. Just want to find out if it
just me or perhaps others have thought of this too: Why shouldn't the
keyset of a dictionary be represented as a set instead of a list?
P I think the order of the
[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
This has been bothering me for a while. Just want to find out if it
just me or perhaps others have thought of this too: Why shouldn't the
keyset of a dictionary be represented as a set instead of a list?
I think this is an interesting
[EMAIL PROTECTED] wrote:
This has been bothering me for a while. Just want to find out if it
just me or perhaps others have thought of this too: Why shouldn't the
keyset of a dictionary be represented as a set instead of a list?
I think the order of the items returned by keys() and values()
Paddy:
Mind you, Never rely on that implied ordering. Always use items().
Using dict.items() is probably better, but the manual says:
If items(), keys(), values(), iteritems(), iterkeys(), and itervalues() are
called with no intervening modifications to the dictionary, the lists will
directly
Nick Vatamaniuc wrote:
Robert Kern wrote:
[EMAIL PROTECTED] wrote:
The same thing goes for the values(). Here most people will argue that
...
This part is pretty much a non-starter. Not all Python objects are hashable.
...
Also, I may need keys to map to different objects that happen
This has been bothering me for a while. Just want to find out if it
just me or perhaps others have thought of this too: Why shouldn't the
keyset of a dictionary be represented as a set instead of a list? I
know that sets were introduced a lot later and lists/dictionaries were
used instead but I
There's a few good reasons.
1 - golden handcuffs. Breaking old code is bad 90% of the time
2 - creating a set MAY be slower.
Python's sets seem to imply to that they will always be a hash map. in
this case, some creative hash map mapping could allow one to create a
set without calculating hash
[EMAIL PROTECTED] wrote:
I can't speak for your code, but this is the most common use of keys in
my coding:
# d is some dictionary
keys = d.keys()
keys.sort()
for k in keys:
#blah
This you can rewrite quite effectively as:
for k in sorted(d):
#blah
--Scott David Daniels
1 - golden handcuffs. Breaking old code is bad 90% of the time
I agree with you on that, mostly for code that counted on list methods
of result of keys() - like you later show with sort. But there is a
side note: old code that assumed a particular ordering of the keys or
values is broken
[EMAIL PROTECTED] wrote:
The same thing goes for the values(). Here most people will argue that
values are not necessarily unique, so a list is more appropriate, but
in fact the values are unique it is just that more than one key could
map to the same value. What is 'seen' in dictionary is
On 2/07/2006 6:01 AM, [EMAIL PROTECTED] wrote:
This has been bothering me for a while.
[snip]
Summary of OP's post: d.keys() and d.values() should return sets in
Python 3.0.
Observations:
(1) My code [some of which dates back to Python 1.5.1] uses about 12 x
d.items() and 11 x d.keys() for
Nick Vatamaniuc [EMAIL PROTECTED] wrote:
But there is a side note: old code that assumed a particular ordering
of the keys or values is broken anyway.
From a testing point of view, it would be interesting if there was a flag
which said, Deliberately change everything which isn't guaranteed
You are correct I should have thought of that. I still think the keys()
method should return a set() though.
Robert Kern wrote:
[EMAIL PROTECTED] wrote:
The same thing goes for the values(). Here most people will argue that
values are not necessarily unique, so a list is more appropriate,
14 matches
Mail list logo
