won’t assign anything to rand_pos, as shuffle() doesn’t return a value. It just acts directly on its argument, like this:
shuffle(target_starting_positions)
Why? I don’t know.
Having said that, target_starting_positions should still get shuffled, and the position of your target stimulus should therefore be randomly selected, regardless of whether you use .pop() or get the first element from the list.
I’d suggest you put in some (temporary) debugging code like:
print(target.pos)
to see if the assignment works as expected. That will help you nail down the issue (eg does it get re-initialised somewhere later before being drawn?)
Unfortunately, that did not work in resetting the circle stimulus. As Michael suggested, I put a debugging code, and it does print a new position, but it is not reflected in the task itself.
and it does print a different starting position every time I run the task, but it’s not getting reflected in the task. The circle stimulus is still stagnant in the center of the screen.
OK, so somewhere between the code above and when the stimulus actually gets drawn, either the position of that stimulus is being reset to [0, 0], or the stimulus gets re-initialised (with the default position of [0, 0]), or it never gets drawn at all, but another similar stimulus does, and so on.
You need to work through your code, following the chain from the portion above (which is clearly working, as your debugging print statement shows), to the place where it actually gets drawn.
e.g. You could short-circuit the process by seeing what happens if, immediately after the code above, you simply put:
target.draw()
Do you see the stimulus at the expected random location, but also another one at the centre?
Lastly, just to verify, is this all actually happening in a script written from scratch, or is this a Builder experiment, with these snippets of code in code components? In the latter case, it is very easy to get conflicts between stimuli defined in code and those created through graphical components.