Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Le jeudi 11 septembre 2008 à 13:48 +0000, Skip Montanaro a écrit : > Actually, I think Python guarantees (for dicts at least - other mappings > should probably follow suit) that if you call keys() then call values() > without making any changes to the dict that their orders match, e.g., that > > zip(d.keys(), d.values()) == d.items()
Perhaps. I've never written any code that relies this, though, and it doesn't sound like an useful guarantee since you can just use the items() method anyway. It probably dates back to an era when list comprehensions didn't exist, and extracting keys or values from the items list required several lines of code and costly method calls. Also, the point is that Python dicts can make that guarantee without being any slower. It may not be the same for an RDBMS backend. Why? Because, depending on the backend, index and data can be stored in separate areas with different storage layouts (e.g. keys are in a B tree while values are just dumped sequentially). If you only ask for unordered keys, they will be read in optimal (sequential) index order, and if you only ask for unordered values, they will be read in optimal (sequential) data order, which is not the same. This is true for e.g. MySQL. (also, IMO this discussion proves that the module shouldn't be included in Python 3.0. It's too young, its API hasn't even settled down) _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3783> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
