[Python-Dev] A cute new way to get an infinite loop

Raymond Hettinger python at rcn.com
Sun Sep 26 12:17:34 CEST 2004


> I think it's easy to fix.  "The usual rule" applies:  you can't assume
> anything about a mutable object after potentially calling back into
> Python.  So trying to save info in "i", "m", or "n" across loop
> iterations can't work, and the list can never be left in an insane
> state ("semi" or not) at any time user code may get invoked.  But
> since we have both "num allocated" and "num used" members in the list
> struct now, it's easy to use those instead of trying to carry info in
> locals.

FWIW, I've searched the codebase and found no other variants on this
problem.  None of the other update/extend methods try to remember self
data between iterations.  Other calls to list_resize immediately fill-in
the NULLS before calling arbitrary Python code.  And, other places that
use the over-allocation trick, map() for example, are working with a
brand new list or tuple that has not been exposed to the rest of the
application.

One situation did look suspect.  _PySequence_IterSearch() remembers an
index/count across calls to PyIter_Next() -- it looks like the worst
that could happen is the index or count would be wrong, but no crashers.



> Patch attached.  Anyone object?  Of course in the example at the start
> of this msg, it leaves x empty.

Looks good.  Reads well. Solves the problem.  The timings are still
fast.  The test suite runs w/o exception.  Please apply.



Raymond



More information about the Python-Dev mailing list