Assertion errors/stale cache in typeobject.c when tp_version_tag is not cleared.

The simple method cache in typeobject.c uses the tp_version_tag field and the Py_TPFLAGS_VALID_VERSION_TAG bit in the tp_flags field to track changes on the type that might invalidate the cache. Unfortunately the code currently assumes that any code clearing the tp_flag also clears the tp_version_tag, and checks this assumption with an assert. Unfortunately, many SWIG-generated extension modules violate this assertion.

SWIG prior to 4.1.0 cleared the tp_flags bit without touching the tp_version_tag field (https://github.com/swig/swig/blob/v4.0.2/Lib/python/pyrun.swg#L1230). This was unintentionally fixed in 4.1.0 by using PyType_Modified() instead, but unfortunately there are a great many SWIG-generated extension modules checked in all over the place (e.g. https://github.com/OSGeo/gdal/blob/6bd07b20b3e55c2fc94da611244a615a4fd2991f/swig/python/extensions/osr_wrap.cpp#L2296) so we cannot assume tp_version_tag is changed when the tp_flag bit is cleared.

The end result is an assertion error when assertions are enabled (I would implore everyone to run tests with assertions enabled...), or potentially a stale cache entry when they are not. It's hard to gauge the likelihood of the stale cache entries. In the case of SWIG it's extremely unlikely, as SWIG merely sets the this attribute on the type, which is not likely to be cached or looked up with _PyType_Lookup. For other cases where extension modules clear the tp_flag bit without changing the tp_version_tag it might be more likely.

(I have a PR to fix this already.)

• PR: gh-99294

• PR: gh-101736

Start in typeobject.c and review the cache invalidation logic around tp_version_tag and Py_TPFLAGS_VALID_VERSION_TAG, then inspect PRs gh-99294 and gh-101736 for the work already underway. Done means the assertion and stale-cache concern are addressed and assertions-enabled tests pass.