> What about instead of unconditionally calling CoInitializeEx in all cases, add a Py_EnsureCOM(flags) C API function?

This is essentially what CoInitializeEx does anyway - if the flags don't match the existing ones, it returns an error. So all we gain is a core function that directly calls CoInitializeEx. (I'm not saying that wouldn't be valuable, but it's also entirely suitable for a 3rd-party package since it requires 3rd-party code to call it.)


> Is there any *other* use case for keeping COM objects (that are created by the core) around?

Haven't found one yet :) IIRC, there's a decent chunk of certificate store APIs that are only available via COM, so if we wanted to enable something like signed scripts (or possibly even migrate ssl to verify using the right APIs on Windows) then we'd probably need it for that. Maybe - though doubtful - it would be feasible to only initialize COM around each connection.

Basically all of the new "cool" APIs added since Windows 8 are COM-based too, so if we wanted to support launching/interacting with modern-style apps (or being embedded in one), or some of the credential support. It's a big hypothetical right now, but given the current state is "we can't use COM because we don't initialize it", we're definitely missing potential opportunities.

If there was an easy way to say "we now initialize COM all the time" then the potential would open up, but since it doesn't look like there's an easy way to do that we'll have to keen on avoiding the new APIs unless there's sufficient value to add the complexity of background threads.