This is true, but it also requires enabling COM (CoInitializeEx), which we historically try to avoid doing on the main thread in case the application wants to enable it differently (e.g. single-threaded vs. free-threaded). The WMI query in _wmi runs on its own thread to avoid touching the main thread's state.

I suspect the overhead of threading would probably take away the benefits here. If we were to go down this route, we'd probably have to figure out how to safely transition to either all CPython or just python.exe (i.e. embedders can choose) running with COM initialised. I dislike this kind of process-wide state being unpredictable (i.e. based on whether anything has done a copy/move/delete).

That said, I believe that Store packaged Python is already doing this, I just haven't tested exactly what the conditions are (specifically whether it's somehow active but the mode can be changed). I'm not aware of anyone hitting issues due to this, but it's possible they just worked around it with a different install. (Under PEP 773, we go back to never having COM initialised by default.)

Apart from that massive caveat, we'd also be formally introducing C++ code (which I've already kind of smuggled in anyway, but it's entirely restricted to the Windows side with only Python-level references, so it's very "clean"). I'm not opposed, but it's a consideration. We're not using the macro nonsense to try and emulate OOP from C 😉

Besides all that, I'd love to see it done. It's just not quite trivial in its impact, unfortunately.