homepage

The work-around that I proposed for issue10700 does not work with Python 2.x:
$ python2.7 dict-graph.py
Vertex 0 -> 2, 1
Vertex 1 -> 
Vertex 2 -> 
Traceback (most recent call last):
 File "dict-graph.py", line 74, in <module>
 p = pickle.dumps(g)
 ...
File ".../Lib/pickle.py", line 661, in _batch_setitems
 for k, v in items:
RuntimeError: dictionary changed size during iteration

It's interesting. The example behaves unstable on 3.3+ with C implementation of picle, sometimes works, sometimes fails. With Python implementation and on 3.2 it works always. On 2.7 it fails always.
A difference between C and Python implementations of pickle is a bug and should be fixed.

I find the posted code mystifying. As the name suggests, __getstate__ should probably not mutate anything.
It would be nice if you could post a simpler example to reproduce issue. Even better if it doesn't have a mutating __getstate__, I would say.

> It's interesting. The example behaves unstable on 3.3+ with C implementation of picle, sometimes works, sometimes fails. With Python implementation and on 3.2 it works always. On 2.7 it fails always.
That's hash randomization.

The mutating __getstate__ is very likely the problem here. I've attached a small test case which shows the described behavior.
We could fix this by always making a copy of any mutable container we want to iterate over to save its items. Performance-wise this solution is not very attractive. We are better off documenting this behavior as a limitation of __getstate__.

I agree with Antoine that, "As the name suggests, __getstate__ should probably not mutate anything."
Unless a problematic non-mutating example can be found, I suggest this be closed. For the most part, our rule has been that pure python code doesn't have to (and possibly cannot) defend itself against mid-stream mutation, while C code only has to defend itself to the point of avoiding a segfault. 
IMO, "RuntimeError: dictionary changed size during iteration" is an informative error message in this case.