On 04/16/2015 05:56 PM, Marc-Andre Lemburg wrote:
> 
> 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.

I'm disappointed that you discredit any other use case besides what you think as
the typical use case as not real life use case.  Maybe you are focused on x86
only, but if you've been to PyCon 2014, you should have a nice Raspberry Pi.
What do you run on it, a soft float, or a hard float distribution? How do you
distribute extensions for that? Yes, you can run both at the same time. There
are now the first 64bit Raspberry Pi like boards (https://www.96boards.org/).
Most of the SoCs can run ARM32 hard- and soft-float binaries, but not all, and
that's why AArch64 gets an ILP32 ABI too. Maybe you don't like the variety in
the ARM world, but's that real life.