# Module slot for checking ABI compatibility **URL:** \ **Category:** Ideas\ **Tags:** c-api\ **Created:** [June 23, 2025, 1:29pm UTC](https://discuss.python.org/t/module-slot-for-checking-abi-compatibility/96443 "2025-06-23T13:29:25Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\ **Post date:** [June 26, 2025, 7:06am UTC](https://discuss.python.org/t/module-slot-for-checking-abi-compatibility/96443/4 "2025-06-26T07:06:16Z")
> [@xuantengh](#): > > So if a extension module is built under a high version interpreter, can it be imported by an old interpreter even if the module itself is fully compatible with the old one. It seems the old interpreter is unable to parse the newly-added slot? Yes – as with any new feature, you can use this once you don’t build for interpreters without the feature. You could check the Python version and hide the slot from old interpreters, but that’s probably too much effort for any gain. (Or, if PEP 793 is accepted for the same Python version, you can include it only for the new hook. Similar with [optional slots](https://discuss.python.org/t/pre-pep-unified-slot-system-for-the-c-api/78873).) > [@da-woods](#): > > That meant that you ended up with (e.g.) freethreading Python trying to load a non-freethreading module, but the module was also somehow linked to non-freethreading Python and was trying to call the functions in that dll. Sounds like this proposal would prevent this? A freethreading Python trying to load a module with “non-FT only” in `PyABIInfo.flags` would fail. > [@da-woods](#): > > So my one warning here is that your new slot would need to be robust to that enormous mess. Do you have a reproducer I could use to test this? --- _[View the full topic](https://discuss.python.org/t/module-slot-for-checking-abi-compatibility/96443)._