Most changes to Pythonrequire a NEWS entry. Add one using theblurb_it web app or theblurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply theskip news label instead.

To be precise, compiling python with./configure --enable-optimizations and measuring withpython -Ximporttime -c "import threading", I am getting 2.44ms on main and 1.17ms on this PR.

Just a thought, is it even necessary to usefunctools.partial here? Could this not be replaced withlambda: f(*args, **kwargs), that would avoid importing functools at all. Is there something I'm missing here?

Just a thought, is it even necessary to usefunctools.partial here? Could this not be replaced withlambda: f(*args, **kwargs), that would avoid importing functools at all. Is there something I'm missing here?

This was my thought as well on first seeing the patch.functools.partial can be faster than alambda function, but here I doubt it makes a significant difference. (If we wanted to check whether using alambda here slowed things down, we'd need to do a benchmark usingconcurrent.futures, since theconcurrent.futures module is the only public API that makes use of this private API. It might be possible to write such a benchmark, but it also might be difficult -- not sure.)

functools.partial can be faster than a lambda function, but here I doubt it makes a significant difference. (If we wanted to check whether using a lambda here slowed things down, we'd need to do a benchmark using concurrent.futures, since the concurrent.futures module is the only public API that makes use of this private API. It might be possible to write such a benchmark, but it also might be difficult -- not sure.)

Looking at the code, thethreading.register_atexit() is only ever called duringconcurrent.futures import, so I would assume any performance difference here would be marginal?

Looking at the code, thethreading.register_atexit() is only ever called duringconcurrent.futures import, so I would assume any performance difference here would be marginal?

Oh, great point 😄

In that case, let's just go with alambda here -- it seems simpler :)

@AlexWaygood thanks!

@ericsnowcurrently, there's no reason why switching to a lambda rather than functools.partial could be problematic for subinterpreter support, is there?

Just a note, if this was a problem, we could still get away with it by simply not doing either: the function is (at least currently) being called without any extra*args or**args arguments so we could make_register_atexit less general and simply pass the callback function directly to_threading_atexits list.

I can't see a way in which this would cause problems — I'll go ahead and merge, since it's been a few days :)

Thanks@danielhollas!

@ericsnowcurrently, there's no reason why switching to a lambda rather than functools.partial could be problematic for subinterpreter support, is there?

I'm not aware of any such reason.