On Mon, Aug 1, 2016 at 12:01 PM Steve Dower <steve.dower@python.org> wrote:
On 01Aug2016 0702, Nick Coghlan wrote:
> On 1 August 2016 at 23:36, Daniel Holth <dholth@gmail.com> wrote:
>> build_ext command determines
>> the DLL extension. It could be patched or modified to read an "I'm ABI3"
>> flag on the Extension() object.
>>
>> We could pass an ABI3 flag to bdist_wheel in the same way we ask for
>> universal 'py2.py3-none-any'. To be set if the wheel contained only ABI3
>> extensions, and ignored on py2.
>
> The general idea sounds good to me, but as a slight bikeshed on the
> flag name, perhaps "cpabi3"?
>
> That's a mash-up of the 'cp' interpreter code for CPython, with the
> 'abi3' stable ABI tag.
>
> Longer term, we may want to allow people to version that (as new APIs
> may sometimes be added to the stable ABI, which you gain access to at
> the C level by setting Py_LIMITED_API to the corresponding CPython hex
> version rather than just defining it [1]), but as a starting point
> enabling access to the initial 3.2 stable ABI used by cffi should be
> sufficient.

The DLL tag on Windows will have to just be ".pyd" if you want to
support back prior to 3.5. In 3.5 you can use ".cp35-win32.pyd" or
".cp35-win_amd64.pyd" and the importer will prefer that DLL over a plain
".pyd", but my proposal to also support ".cp3-${PLAT}.pyd" here didn't
make it.

The wheel tag is more important than the DLL tag. (Possibly you're not
even suggesting changing the DLL name at all and just passing the flag
through for the build option? Hard to tell from the discussion.)

I'm sure we are interpolating from Linux, where you'd be looking at extensions .cpython-35m-x86_64-linux-gnu.so versus .abi3.so. But any DLL extension that the target CPythons will agree to load, plus an appropriate wheel tag, should be sufficient for our use case.