Python has in importlib.machinery.EXTENSION_SUFFIXES a list of strings representing the recognized file suffixes for extension modules.

Sagemath defines loadable_module_extension() as the first entry in the list, and assumes extension modules use this suffix only.

This is normally ok since python setuptools uses that particular suffix when compiling extension modules.

However, this may not always be true. For example in void linux the extension modules are renamed to use the shortest suffix (which is .so, instead of .cpython-310-x86_64-linux-gnu.so).

I don't know what's the rationale behind that rename, but it's "legal" from pov of python, so it'd be nice if this was supported in sage.

There is one doctest failure on this situation:

**********************************************************************
File "src/sage/misc/sageinspect.py", line 186, in sage.misc.sageinspect.loadable_module_extension
Failed example:
    sage.structure.sage_object.__file__.endswith(loadable_module_extension())
Expected:
    True
Got:
    False
**********************************************************************

Moreover, this causes another (more serious) issue in sage.misc.sageinspect.sage_getfile, namely:

sage: sage.misc.sageinspect.sage_getfile(x)
'/opt/sage/sage-git/develop/pkgs/sagemath-standard/build/lib.linux-x86_64-3.10/sage/symbolic/expression.so'

The expected output is the full path to expression.pyx instead of .so.

It turns out this is handled by a fallback in sage_getfile that is not covered by any doctest.

Purpose of this ticket is
a. add a doctest that exercises the above example so it triggers this incorrect behaviour.
b. fix the incorrect behaviour of sage_getfile
c. look for other possible incorrect uses of loadable_module_extension() which are making the same assumption

Component: porting

Author: Gonzalo Tornaría

Branch/Commit: fd46c83

Reviewer: Matthias Koeppe

Issue created by migration from https://trac.sagemath.org/ticket/33626