I'm not sure we care, but we might -- am I right that this writes pickles that can't be read by 3.11 or before?

No, absolutely no. I would never propose such change.

Internals will be different, but the unpickled iterator wil produce the same values.

This is a little scary -- if the new length is set but computing the new start fails, and the original iterator is still accessible, it will be truncated at the end rather than at the start. Let's update both fields after all errors have been checked.

Ditto in next().

Good point. Although__setstate__ is only supposed to be called for just created object when unpickle or make a deep copy, so there are no references to that iterator yet.

But there were other issue here.state could be a borrowed reference tor->len. It is used in two places: withPyNumber_Subtract() and withPyNumber_Multiply(). The second time it is used after setting the newr->state, when it can refer to a freed memory.

next() does not have such issue.

Seems that it never happens in normal code. You have to call__setstate__() manually with the out-of-range value.

I don't see a scenario where we can't just use

Py_SETREF(r->len, new_len);Py_SETREF(r->start, new_start);

(which would be a little easier to follow).

Bothnew_len andnew_start are definitely new references we own, so even ifstate was a borrowed reference tor->len everything would be all right.

I'll leave it up to you though.

Py_SETREF can only help when you assign a single object attribute, or if the attributes are independent. Two sequentialPy_SETREFs can be a sign of a bug.

We do not check the type ofstate. It can be an arbitrary Python object with methods__lt__,__gt__,__mul__ and__rsub__. Therefore we do not control the types ofnew_len andnew_start. Therefore we do not control the types ofr->len andr->start. They can have__del__ methods which release the GIL after assignment inPy_SETREF. When the GIL is released, the iterator object can be used in other thread when it is in inconsistent state -- newr->len and oldr->start.

It never occurs in normal code (state is always an exact int), but if you try hard, you perhaps can reproduce this.

Aha, that's a scenario I hadn't considered. Maybe the next time I am asked in some kind of Q&A or interview "do you have any regrets" I should mention__del__ methods.