Windows and the major POSIX platforms (including Linux and macOS) now support loading C extension with a version-tagged name (and build them likewise), such as "foobar.cpython-36.so".

Following the discussion in https://mail.python.org/pipermail/python-dev/2017-December/151328.html, I propose to remove the ability to load untagged C extension names on those platforms.  IOW, "foobar.dll" or "foobar.so" will not be recognized when "import foobar" is executed anymore.

Interestingly, the test suite doesn't seem affected at all.

Actually, let me correct this: the build fails on Windows (see AppVeyor).  That's because the Windows build process, for some reason, produces untagged pyd files.

If I'm understanding correctly, the ".pyd" extension is hardcoded in the various ".vcxproj" files.  Which means this PR would need the help of a Windows expert to progress forward :-S

+1 on doing this.

It might also be worth examining all of the latest package version wheels on pypi to see which packages claiming to support Python 3 have binary wheels containing untagged .pyd or .so files.

Also, even if they are common, it seems reasonable that pip could be trained to rename untagged binaries on install after doing something to determine if they should be compatible with >=3.7 or not.

cc'ing people for the pip/PyPI aspects of this.

If needed I could help upload the updated project files here for this issue.

Attached is my changes to the vcxproj files based on an field already in python.props.

Please don't rush this in, at least for Windows. I deliberately decided to keep the included pyd files untagged for a reason, and need to recall what that was. (It might be in the issue when we added the tags.)

Considering a .pyd file linking against pythonXY.dll is only going to load in the context of that version anyway, this is hardly urgent. There is also no supported tag on Windows for building against the stable ABI, so that would have to be added and enabled in the various build tools.

Thanks for the heads-up Steve.

> Considering a .pyd file linking against pythonXY.dll is only going to load in the context of that version anyway, this is hardly urgent.

I see.  That's a good argument for keeping the current extensions list, then.  We can narrow the change to POSIX platforms.

With my macOS hat on, I don't see a problem with doing this.  C extensions built via Distutils have been version-tagged on macOS since 3.5.0 (for some reason, macOS was skipped when PEP 3149 was originally implemented).

With my release manager hat on, it sounds like a good idea.  But it could introduce a compatibility problem for anyone who doesn't use Distutils to produce extension modules.  So I'd like to see this proposal get a little more visibility, at the minimum, bringing it up on the Distutils SIG mailing list.  We should also ensure that the change gets mentioned in the 3.7 What's New document.  And somewhere in the docset there should be some documentation for the .so file name requirements.  AFAICT, today it's really not mentioned anywhere in the docs other than the reference to PEP 3149 in the 3.2 What's New.  Until the packaging documents for extension modules get overhauled perhaps something could be added to the Building chapter of the Extending and Embedding document:
https://docs.python.org/3/extending/building.html#building-c-and-c-extensions

did this get discussed on distutils-sig?  It's a trivial change (for the POSIX only PR) and would be neat to go through one of the 3.7 beta cycles to see if anything serious an unexpected is likely to come up for anyone.

+1

So, just for clarity, is there another approved mechanism for distributing an extension that just happens to act as a (Python version specific) C support library? I've wanted to be able to build a library (static or dynamic) that is installed to lib/pythonX.Y/site-packages so it can be found by other extensions that use it without them having to ship a copy themselves.

The best solution I found was building and installing untagged extensions with pip; the extension features weren't actually used for anything but unittesting the library, but making it an extension meant it got installed to the Python version specific site-packages.

If untagged extensions aren't just old-fashioned, but banned, my use case is broken, and I've been completely unable to find a decent, non-Cython based, setup.py based pattern for building a C library that provides wrappers for Python API calls (and therefore must target specific Python versions).

Interesting use case Josh.  I don't know of a good way to deal with non-extension-module Python API using .so files.  I like your extension hack, but what is the problem with having the version embedded in the .so name?

Not sure if this has missed the 3.7 train, but bumping this to check if the discussion on distutils-sig ever occurred and what the  result of it was. (Otherwise the PR just needs a news entry and it should be ready.)

As far as I know, it has not been discussed elsewhere and I think the potential for breaking third-party distributions is too high to risk making this change this late in the release cycle, independent of Steve's concerns in msg308878.  Unless someone can dispel those concerns prior to the imminent 3.7.0b3 ABI freeze, I think this should be deferred to 3.8.

It's 3.8 time now. :) Should we try and resolve this?

I think it'd be worth doing on POSIX systems for some 3.8 alpha/beta release cycles before making a final call there.