Iterating SingleFrame readers does not call rewind()

[IAlibay]

Indirectly related to #3416

Expected behavior

All readers should behave similarly.

Actual behavior

See: #3415 (comment)

Iterating a SingleFrame reader does not rewind the reader, which means that any modified coordinates remain the same. This differs in behaviour from the trajectory readers which do rewind (and therefore update positions).

Code to reproduce the behavior

import MDAnalysis as mda
from MDAnalysisTests.datafiles import two_water_gro, GRO, XTC

# single frame
u = mda.Universe(two_water_gro)

assert u.atoms[0].position[2] != 0

for at in u.atoms:
    at.position = at.position[0], at.position[1], 0

assert u.atoms[0].position[2] == 0

for ts in u.trajectory:
    pass

assert u.atoms[0].position[2] == 0

# trajectory
u = mda.Universe(GRO, XTC)

assert u.atoms[0].position[2] != 0

for at in u.atoms:
    at.position = at.position[0], at.position[1], 0

assert u.atoms[0].position[2] == 0

for ts in u.trajectory:
    pass

assert u.atoms[0].position[2] != 0

Current version of MDAnalysis

• Which version are you using? (run python -c "import MDAnalysis as mda; print(mda.__version__)") develop
• Which version of Python (python -V)? 3.8
• Which operating system? All under CI

[orbeckst]

I would like to label this issue a defect. I don't think that a fix is a API change because the behavior was never intended or documented as such. I would consider a fix a fix for the API that makes the SingleFrameReaders behave consistent with the existing API.

[orbeckst]

If anyone disagrees please chime in.

(Note that if it's not a defect then we can only change it in 3.0 because under semantic versioning it would be a breaking API change.)

[IAlibay]

I'm on board with calling this a defect. There is however a possibility that folks may have unknowingly been relying on this behaviour, so we should make sure we advertise the change well.

[orbeckst]

Note that PR #3642 fixes the undefined behavior to rewind before iteration.