classification
Title: Data lost randomly from dictionary after creating the dictionary
Type: behavior Stage: resolved
Components: Versions: Python 3.8
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Y3Kv Bv, tim.peters
Priority: normal Keywords:

Created on 2020-01-14 22:23 by Y3Kv Bv, last changed 2020-01-15 00:40 by tim.peters. This issue is now closed.

Files
File name Uploaded Description Edit
test.py Y3Kv Bv, 2020-01-14 22:23 Example code that triggers dic data loss
Messages (5)
msg360007 - (view) Author: Y3Kv Bv (Y3Kv Bv) Date: 2020-01-14 22:23
Windows 7 x64, Python 3.8.1

I've encountered a very weird issue where after creating a dictionary from a list the dictionary ends up being shorter/data is lost from it.
It's absolutely random when it loses, how many and which items are lost.

I've attached the example file with the code that always has a chance to trigger the issue for me.

I've managed to figure only this much that when "if useAmp" never triggers, data loss will never occur. I've added checkpoints to verify where the loss occurs and it's not caused by "if useAmp" block directly, data loss happens exactly after the dictionary is created.
msg360008 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2020-01-14 22:55
I suspect your `useAmp` branch is not doing what you think it's doing: it's effectively replacing a random number of entries in your `crazyQuilt2` list with a duplicate entry (try `print`ing the list every time around the main loop to see what's happening to it).  When you later create a dict using the entries of the list as keys there are only so many unique keys, and thus the dict is not the same length as the list.
msg360010 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2020-01-14 23:01
What, exactly, in the output shows "the problem"?  When I run it, the `a == b` part is always True, while `len(x)` and `len(crazyQuilt2)` are always 30.  The other three (len(coordinates), len(x2), len(x3)) are always equal to each other, but are monotonically non-increasing across output lines.  For example, a typical block of output lines:

(True, 30, 30, 30, 30, 30)
(True, 30, 30, 30, 30, 30)
(True, 30, 30, 30, 30, 30)
(True, 30, 30, 30, 30, 30)
(True, 19, 30, 30, 19, 19)
(True, 19, 30, 30, 19, 19)
(True, 19, 30, 30, 19, 19)
(True, 12, 30, 30, 12, 12)
(True, 12, 30, 30, 12, 12)
(True, 12, 30, 30, 12, 12)

None of that surprises me.  Exactly what about it surprises you?  Or do you get different kinds of output (and, if so, exactly what?)?

Here's my guess:  you _intended_ these two lines:

          crazyQuilt2[coordinate2Index] = crazyQuilt2[index]
          crazyQuilt2[index] = crazyQuilt2[coordinate2Index]

to _swap_ the values at indices `index` and `coordinate2Index`.  But they don't.  They copy the value originally at `index` into the `coordinate2Index` position, and leave the value originally at `index` untouched.

As more copies randomly build up, anything that builds a set or dict out of the list naturally gets smaller.
msg360011 - (view) Author: Y3Kv Bv (Y3Kv Bv) Date: 2020-01-14 23:11
I'm a newbie at Python, also obviously not thinking hard enough over Python's mechanics. Shame on me.
msg360015 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2020-01-15 00:40
No problem!  If you are trying to swap the values in two variables `x` and `y`, in most languages that's spelled:

    temp = x
    x = y
    y = temp

and that works in Python too.  But in Python it's more common to do it with a one-liner:

    x, y = y, x
History
Date User Action Args
2020-01-15 00:40:44tim.peterssetmessages: + msg360015
2020-01-14 23:11:31Y3Kv Bvsetmessages: + msg360011
2020-01-14 23:02:31tim.peterssetstatus: open -> closed
resolution: not a bug
stage: resolved
2020-01-14 23:01:12tim.peterssetstatus: closed -> open
nosy: + tim.peters, - zach.ware
messages: + msg360010

resolution: not a bug -> (no value)
stage: resolved -> (no value)
2020-01-14 22:55:49zach.waresetstatus: open -> closed

nosy: + zach.ware
messages: + msg360008

resolution: not a bug
stage: resolved
2020-01-14 22:23:01Y3Kv Bvcreate