In light of #7914, I'm wondering if this should have actually been a warning rather than a failure. We could have simply chosen not to use the ABI module type and to have used our local type instead. The consequences would be:
- using "foreign" cyfunction/generator/coroutine types is no longer optimized. I don't think that's a big deal, and we already do it to an extent with limited API vs regular API types or types with different build flags.
- possibly pickling of functions might fail due to the misleading module name for cyfunction?
Needs a bit of a check about how it interacts with the shared utility code (but it's probably fine).
My reasoning is:
- it's a fairly dramatic failure for something that we can work around
- we don't control the namespace of the shared ABI module so it's a fairly easy way for someone else (or ourselves...) to block Cython modules from loading
- Just as an example for how it could happen accidentally - it's increasingly easy for people to make an AI-modified local fork of Cython to cover their specific use-case. Which would be fine, unless they change cyfunction and block out "real" Cython modules from loading.
In light of #7914, I'm wondering if this should have actually been a warning rather than a failure. We could have simply chosen not to use the ABI module type and to have used our local type instead. The consequences would be:
Needs a bit of a check about how it interacts with the shared utility code (but it's probably fine).
My reasoning is: