On Thu, Jun 24, 2010 at 10:50 AM, Barry Warsaw
<barry@python.org> wrote:
The idea is to put the Python version number in the shared library file name,
and extend .so lookup to find these extended file names. So for example, we'd
see foo.3.2.so instead, and Python would know how to dynload both that and the
traditional foo.so file too (for backward compatibility).
What use case does this address?
PEP 3147 addresses the fact that the user may have different versions of Python installed and each wants to write a .pyc file when loading a module. .so files are not generated simply by running the Python interpreter, ergo .so files are not an issue for that use case.
If you want to make it so a system can install a package in just one location to be used by multiple Python installations, then the version number isn't enough. You also need to distinguish debug builds, profiling builds, Unicode width (see issue8654), and probably several other ./configure options.