Thanks @kumaraditya303 for the PR 🌮🎉.. I'm working now to backport this PR to: 3.11.
🐍🍒⛏🤖

Thanks @kumaraditya303 for the PR 🌮🎉.. I'm working now to backport this PR to: 3.11.
🐍🍒⛏🤖

Sorry, @kumaraditya303, I could not cleanly backport this to 3.11 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker d9de0792482d2ded364b0c7d2867b97a5da41b12 3.11

GH-101722 is a backport of this pull request to the 3.11 branch.

This makes no sense to me.

Static types should be immutable; their version number should never change.

See #101603

Static types should be immutable; their version number should never change.

It is still the case but when the interpreter is initialized multiple times then the type still has the same old version tag and can cause assertion failures. Note that the type cache is per interp now and is cleared on every cycle. See https://github.com/python/cpython/actions/runs/4112993949/jobs/7098592004 as an example.

I don't think that this PR fixes the root problem, although it almost certainly no worse than what we had before.

What assertions fails? "Can cause assertion failures" doesn't tell me anything.

When you say "the interpreter" how does this handle sub-interpreters?
The problems are that heap and static types are sharing the same versions, and that versions are shared across interpreters.

@ericsnowcurrently might have thoughts on this.

What assertions fails? "Can cause assertion failures" doesn't tell me anything.

See the GH Action run that Kumar linked to for an example. I'll quote it for you:

This is from test_finalize_structseq in test_embed.

When you say "the interpreter" how does this handle sub-interpreters?
The problems are that heap and static types are sharing the same versions, and that versions are shared across interpreters.

As @kumaraditya303 mentioned in gh-101696, subinterpreters will be dealt with via gh-95795.