[Tutor] results not quite 100 percent yet

[Kent Johnson]

bhaaluu wrote:
> On Jan 30, 2008 8:24 AM, Kent Johnson <kent37 at tds.net> wrote:
>> bhaaluu wrote:
>>> Now that you mention it, I do seem to remember that the order of
>>> a list is indeterminate.
>> No; the order of a dict is indeterminate, and consequently the order of
>> lists derived from dicts with keys(), values(), etc. is indeterminate.
> 
> The order of the dictionary is indeterminate. But the key is always
> attached to the value, and in my case, the value is a list, so
> 
> print tablE.keys() #prints all the keys [in an ordered list, 1-19]

This is implementation dependent. You should not depend on the order of 
elements in tablE.keys()

> print tablE.keys()[5] #prints the key, 6

This is implementation dependent.

> print tablE.values() #prints a list of [all [the lists]]

Yes. The order of the list (of lists) is implementation dependent.

> print tablE.values()[5] #prints only the [list for key 6]

This is implementation dependent and pointless. You are not using the 
dict at all except as a way to store a list of lists. Either use 
tablE[6], which will always return the list associated with the key 6, 
or just keep your lists in a list directly.

> So what you're saying here is that while it might work okay on
> my system, that this may not work the same way on another
> system?

Yes. The order of keys() and values() is implementation dependent. It 
may change with different versions of Python and different 
implementations. It can also change as you add more elements to the dict.

(For example, one problem the Jython folks have had getting Django to 
run on Jython is that the Django unit tests make assumptions about the 
order of dict values. These assumptions are not true in Jython and the 
unit tests fail.)

>         if travelTable.values()[roomNum-1][0] != 0:

Again, the use of travelTable.values() is pointless, inefficient (it 
creates a new list every time you call it) and indeterminate. Really, 
you shouldn't be doing this. I can't think of any reason to code this way.

Kent