[ python-Bugs-1612113 ] Dictionary ordering docs are too unclear of dangers

SourceForge.net noreply at sourceforge.net
Fri Dec 29 23:03:29 CET 2006


Bugs item #1612113, was opened at 2006-12-09 12:57
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Calvin Spealman (ironfroggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dictionary ordering docs are too unclear of dangers

Initial Comment:
The footnote #3 on this page of the documentation details some thoughts on the order of dictionaries and the results of the different key and value retreival methods. I think it promises more than it should. The current content tells the reader they can expect consistant results from a dictionary as far as order goes, and we know this to be simply untrue and even in the circumstances where its likely (but still not impossible), such as `zip(d.values(), d.keys())` there is not even any compelling reason to use such odd methods, making the very fact that the idea is documented suspect.

I recommend the footnote be removed entirely, or replaced with "Keys and values are listed in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary's history of insertions and deletions. Do not expect anything of the order of the items(), keys(), values(), iteritems(), iterkeys(), and itervalues() methods' results." 


Page in question:
http://docs.python.org/lib/typesmapping.html

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2006-12-29 23:03

Message:
Logged In: YES 
user_id=21627
Originator: NO

It can't fail just because of the presence of threads or weakref
callbacks, unless these perform modifications to the dictionary. Such
modifications can, of course, also happen in a regular loop, if the code in
the loop performs the modification (either directly or indirectly, through
function calls).

As Tim says: if it hurts your feelings to make such an assumption, then
just don't make it for yourself (i.e. don't rely on it in your own
programs).

----------------------------------------------------------------------

Comment By: Calvin Spealman (ironfroggy)
Date: 2006-12-24 17:27

Message:
Logged In: YES 
user_id=112166
Originator: YES

This would only fail with the use of threads or weakref callbacks, most
likely. I still think thats enough reason to take them back out. Assuring
any order at any time, reguardless of the circumstances, I feel, is just
against the concept of the dictionary.

----------------------------------------------------------------------

Comment By: SourceForge Robot (sf-robot)
Date: 2006-12-24 04:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2006-12-09 15:51

Message:
Logged In: YES 
user_id=31435
Originator: NO

The statement that the various ways of extracting info from a dict are
consistent /provided that/ they're "called with no intervening
modifications to the dictionary" (did you miss that crucial qualification?)
is part of the language definition:  it definitely and deliberately
constrains the set of possible implementations.

The docs didn't originally say this, but people noted it was true in
then-current CPython, and asked whether they could rely on it.  At that
point, Guido decided to elevate this property of the CPython implementation
to a language requirement, and the footnote was added.

Of course you're not /required/ to rely on it ;-).


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2006-12-09 15:31

Message:
Logged In: YES 
user_id=21627
Originator: NO

You seem to be saying (without actually saying it) that the footnote is
untrue. Can you give an example that demonstrates it is untrue?

I believe the footnote is correct, precise, and complete as it stands, and
fail to see a bug here.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&group_id=5470


More information about the Python-bugs-list mailing list