We should confirm with @markshannon whether we should fix the interpreter or f_locals. Maybe it's a valid assumption? PEP 667 does not implement everything dict-like for FrameLocalsProxy, but maybe this is necessary? We are adding a small overhead to a very commonly used instruction if I understood it correctly.

I looked at PEP 668 and it seems to assume that mutating f_locals is supported, which makes me think that we need to add this check. I wouldn't personally mind blocking the f_locals mutation instead if you can find a principled way to do it.

We are adding a small overhead to a very commonly used instruction if I understood it correctly.

Yes, that's right; we're adding a NULL check and a branch. However, FOR_ITER has a couple of specialized versions, so the overhead should be minimal when iterating over the most common types. Still, it may be worth benchmarking how bad the overhead is.

Thanks for your advice, it definitely looks better now.

But I have a question.
Is it possible to make the piece of code in the original issue correct?
Why we can't assign different value to the iterator object directly through the frame's f_locals?
I can't see something like this in PEP 667.

It seems that this code is incorrect now:

g = (x for x in range(10))
g.gi_frame.f_locals['.0'] = range(20)

But very similar code is correct:

g = (x for x in range(10))
g.gi_frame.f_locals['.0'] = iter(range(20))

Maybe, some change in framelocalsproxy_setitem function can be provided?
Something like this:

if (_PyUnicode_EqualToASCIIString(key, ".0")) {
    PyObject *it = PyObject_GetIter(value);
    if (it != NULL) {
        value = it;
    }
} 

I've provided this change, but it breaks two tests: test_proxy_key_stringlikes_overwrite and test_proxy_key_stringlikes_ftrst_write. Those tests are authored by @encukou and @ncoghlan.

Setting .0 to a iter(range(20)) should work for now, yes. I don't know what you're trying to use this for at a higher level, but I'd recommend trying to find a solution that doesn't involve mutating f_locals; that's a low-level interface that should probably only be used by tools like debuggers.

I would oppose adding special handling in the FrameLocalsProxy that mutates objects; doing so would complicate the implementation and make it less useful for tools like debuggers.

Actually, there is no real world use case when changing underlying iterator for a generator is needed.
And I understand that f_locals is a low-level interface.

Main purpose of my questions is achieving some clarity.
That's totally okay if the current code behavior is desired.
Maybe just some piece of docs about this use case should be provided.
And, of course, raising the appropriate exceptions is much better than crashing.

I've moved my test from test_generators.py to test_frame.py, renamed it, and added more test cases to emphasize current code behavior and save it explicitly in tests.
IMHO, there is still a room to improvement.

See #125178