MAINT: Import time: Avoid importing python.Threading

[hmaarrfk]

See here:
#14083

Just testing on CIs for now.

[hmaarrfk]

@eric-wieser do you know why azure won't run on this? I'm pretty sure CPython will work, just not PyPy.

[seberg]

I think some heisenbug or so on windows came up a bit often on azure the last few PRs? (not quite sure though).

[hmaarrfk]

Yeah, I think so too.

[seberg]

It seems to me that the _thread method might be choking the pypy test? (i.e. that lock waits forever?). How OK is it really to use the _thread name?

[hmaarrfk]

The python STL was documenting it.

But I guess I misunderstood what they meant by low level.

https://docs.python.org/3/library/concurrency.html

I kinda knew I was doing a bad thing, so I didn't try it first. I think I might have to rerun initial benchmarks now that some of the other PRs are going through

[seberg]

Dunno, it seems that python might have started to endorse _thread specfically, and possibly pypy just has a bug.

[hmaarrfk]

I have to start rerunning these benchmarks again. Some of these fixes are related to deprecation cleanups. Others like this one are more hazy. One could argue that importing from _thread is obscure and shouldn't be done even if it was supported by both PyPy.

[hmaarrfk]

root@c766aae4e273:/# pypy3.6-v7.1.1-linux64/bin/pypy3 
Python 3.6.1 (784b254d6699, Apr 14 2019, 10:22:42)
[PyPy 7.1.1-beta0 with GCC 6.2.0 20160901] on linux
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``snow, snow''
>>>> import _thread
>>>> from _thread import allocate_lock as Lock
>>>> Lock
<built-in function allocate_lock>

This seems to work on the latest downloaded PyPy

[eric-wieser]

How does this behave on systems whether threading is unavailable?

[hmaarrfk]

Oh I guess that is what dummy threading was for. Not too sure for now. PyPy has threading right?

[seberg]

But you can compile python without threading. PyPy should fail the import if it had no threading, but it seems rather that it hangs on an infinite Lock somewhere.

[mattip]

I am not sure about this PR. It seems to increase code fragility for a minimal decrease in import time.

[hmaarrfk]

I think it might have a more measurable effect once #14097 gets pulled in. I was able to get down to 70 ms in my original omnibus PR. I can bechmark after that gets approved again.

[hmaarrfk]

It might be difficult to see the results of this without getting rid of a shutil import in _datasource. shutil ends up importing many different compression formats trying to see if they are installed in a pythonic way at import time.

Unfortunately, bz2 imports Threading just for RLock. I think a PR can be made upstream to use the lightweight _thread module there too.
https://github.com/python/cpython/blob/master/Lib/bz2.py#L17

[hmaarrfk]

I'm not sure upstream will accept using _thread.RLock as they specifically created a workaround for it.

https://github.com/python/cpython/blob/master/Lib/threading.py#L95

That said, even pypy has RLock implemented in C, so maybe :/.

It might be more fruitful to fix upstream. They don't seem to have a c implementation of excepthook which is causing traceback to be imported when the threading module is imported.
https://github.com/python/cpython/blob/master/Lib/threading.py#L1128

[hmaarrfk]

FYI, it seems that the above comment is under development, and might actually be fixed in python 3.8.