Marc-Andre Lemburg added the comment: On 16.04.2015 17:30, Matthias Klose wrote: > > Matthias Klose added the comment: > > Nick filed issue #23966 to document these changes. Yes, these tags should be > documented, so that installers don't have to guess (currently they are only > exposed in importlib.machinery.EXTENSION_SUFFIXES. > > What you describe as a "simple idea" is just another hack, only addressing > the issue on x86 platforms, not addressing this for soft-float/hard-float > calling conventions, not addressing this for endianness, not addressing this > for other platform ABIs. And for all these cases there are machines where you > can run the variants on the same machine. If you like to call this "a mess", > fine. But this is reality. I'm not creating this mess, I'm describing this > and exposing it to the interpreter.
The simple idea Antoine had was to be able to install C extensions compiled for different bit architectures, but the *same platform* into the same directory, which is similar to what we're doing for Python byte code files. The typical use case is to have a 32-bit version and a 64-bit version on the same system. It seems that the scope of this simple idea has now completely blown up in trying to stuff all kinds of other platform features into the binary names as well. And while doing so, we now have different naming styles on different platforms, require hand written configure files to support additional platforms, and have yet another system for associating platform information with binary Python files, in addition to PEP 3149, PEP 425 and PEP 427. See http://bugs.python.org/issue22980#msg232729 I don't think this is a good development and I can hardly imagine a use case where all those different ABIs will have to live on the same machine and in the same directory. At the same time you are creating incompatibilities which did not exist before, by requiring configure script fixes for "unknown" platforms. I'm -1 on these changes. I was +0 on Antoine's original idea, since that addresses real life use case you can run into every now and then. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22980> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com