Issue 31370: Remove support for threads-less builds

The --without-threads option has a lot of repercussions on the code base, forcing us to maintain specific paths for builds with threads disabled, for no useful purpose.

See discussion in https://mail.python.org/pipermail/python-dev/2017-September/149156.html

Question: should we keep Modules/Setup.config.in?  It's going to become empty:
https://github.com/python/cpython/blob/master/Modules/Setup.config.in

The PEP 11 should be updated just to mention that platforms without threading support are not supported in Python 3.7.

We had a buildbot testing --without-threads, but it's gone. I just removed its unused class from the buildbot configuration:

https://github.com/python/buildmaster-config/commit/091f52aa05a8977966796ba3ef4b8257bef1c0e9

I guess Setup.config.in can go.  It's only purpose was for autoconf driven Setup changes.

New changeset a6a4dc816d68df04a7d592e0b6af8c7ecc4d4344 by Victor Stinner (Antoine Pitrou) in branch 'master':
bpo-31370: Remove support for threads-less builds (#3385)
https://github.com/python/cpython/commit/a6a4dc816d68df04a7d592e0b6af8c7ecc4d4344

PEP 11 was updated, the change was merged, this issue can now be closed. Thanks Antoine!

Also 'import threading' code in Tools/scripts/run_tests.py should be cleaned.

Lib/_dummy_thread.py and Lib/dummy_threading.py were deleted, but Doc/library/_dummy_thread.rst and Doc/library/dummy_threading.rst still exist.

Probably Doc/whatsnew/3.7.rst should mention that these modules were deleted.

Or maybe they should be restored and firstly deprecated, before deletion in a later version of Python.

Arfrever: "Lib/_dummy_thread.py and Lib/dummy_threading.py were deleted, but Doc/library/_dummy_thread.rst and Doc/library/dummy_threading.rst still exist."

Ah, it should be deleted as well.

Arfrever: "Probably Doc/whatsnew/3.7.rst should mention that these modules were deleted."

Right.

Arfrever: "Or maybe they should be restored and firstly deprecated, before deletion in a later version of Python."

I don't think that it's worth it, but I suggest to add a warning to Python 3.6 documentation. Something like the following warning in Python 2.7 documentation of the commands module:
"Deprecated since version 2.6: The commands module has been removed in Python 3. Use the subprocess module instead."
https://docs.python.org/2/library/commands.html

Oh, Arfrever wrote me on IRC that the removal of dummy_threading broke portage on Gentoo: https://bugs.gentoo.org/630730

eventlet also uses dummy_threading:

eventlet/support/dns/entropy.py:23:    import dummy_threading as _threading
eventlet/support/dns/resolver.py:29:    import dummy_threading as _threading

Hum, maybe we need one release with the deprecated module, and only remove it in Python 3.8?

+1 to restore dummy_threading and go through a proper deprecation phase in 3.7+.

-0 to restore _dummy_thread. It's an internal, private module.

Following lines needs updating:

Lib/importlib/_bootstrap.py:1135
Lib/_pydecimal.py:436
Lib/test/ssl_servers.py:11
Lib/test/support/__init__.py:2053
Lib/test/test_httplib.py:1080
Lib/test/test_idle.py:4
Lib/test/test_multiprocessing_main_handling.py:3
Lib/test/test_thread.py:5
Lib/test/test_threadsignals.py:8
Lib/test/test_tools/test_sundry.py:43
Lib/test/test_winreg.py:7
Lib/test/test_wsgiref.py:256
Lib/test/test_xmlrpc.py:1179

dummy_threading should definitely not have been removed, and like all the other APIs should not be removed until 2.7 is dead.  Deprecating it is of course fine :)

And actually, I wouldn't be surprised if eventlet depended on the *functionality* in _dummy_threading, so you probably need to restore that, too.

> eventlet also uses dummy_threading

Not sure what you mean by that.  eventlet uses the regular try/except import dance around "import threading":

https://github.com/eventlet/eventlet/blob/master/eventlet/support/dns/entropy.py#L20-L23
https://github.com/eventlet/eventlet/blob/master/eventlet/support/dns/resolver.py#L23-L26

As for portage, Arfrever fixed it :-)

https://gitweb.gentoo.org/proj/portage.git/commit/?id=504f66b0e25281e4465ebeceb799c3e54ff2b884

That said, I am not against bringing dummy_threading back, though it would sound rather weird to use it unconditionally...

https://github.com/python/cpython/pull/3648 restores dummy_threading and _dummy_thread, but deprecates them.

New changeset b43c4caf81b10e5c7ebaeb3a712c6db584f60bbd by Antoine Pitrou in branch 'master':
Restore dummy_threading and _dummy_thread, but deprecate them (bpo-31370) (#3648)
https://github.com/python/cpython/commit/b43c4caf81b10e5c7ebaeb3a712c6db584f60bbd

New changeset 88c60c9668f0aa732693517a60b851cc1dfce0cb by Antoine Pitrou in branch 'master':
Trivial cleanups following bpo-31370 (#3649)
https://github.com/python/cpython/commit/88c60c9668f0aa732693517a60b851cc1dfce0cb

New changeset eef059657d6b10babdb4831e1148d60cc644ee9a by Brian Curtin (Zackery Spytz) in branch 'master':
bpo-31370: Remove references to threadless builds (#8805)
https://github.com/python/cpython/commit/eef059657d6b10babdb4831e1148d60cc644ee9a

Unfortunately, this also leads to less good LTO if you use a single static executable, similar to what Tools/freeze produces but including libpython itself. I'm currently trying to make LLVM do that, but since I can't build without threads, it'd be extremely hard to tell it that it can remove all threading related things (like TLS) and inline them. This means I'll have to patch CPython on my own to remove thread support, but unfortunately this also means I can't guarantee that it continues to work, as well as that it makes it a lot more likely that my build won't support many third-party libraries.

stage: patch review -> resolved