[issue27417] Call CoInitializeEx on startup

Steve Dower added the comment: Mark's argument is strong, so I'm withdrawing this proposal. Thanks for the discussion and comments, everyone! -- resolution: -> rejected status: open -> closed ___ Python tracker

[issue27417] Call CoInitializeEx on startup

Changes by Thomas Heller : -- nosy: +theller ___ Python tracker ___ ___ Python-bugs-list

[issue27417] Call CoInitializeEx on startup

Mark Hammond added the comment: > > This may well break things like pythonwin until they also grow support > > for the new param > I expect that, which is why I'm only proposing it for 3.6 onwards. While > adding support for a new major version of Python should be fairly cheap, > it isn't

[issue27417] Call CoInitializeEx on startup

Paul Moore added the comment: I presume by "we" you mean "the core"? There's nothing to stop 3rd party code using COM APIs. The only downside to using COM in (user) Python code at the moment is the need for a dependency on pywin32 (robust, mature, but a big dependency) or comtypes

[issue27417] Call CoInitializeEx on startup

Steve Dower added the comment: > 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

[issue27417] Call CoInitializeEx on startup

Paul Moore added the comment: > This doesn't work when COM objects have to be kept around. In the AMSI case... OK, so that's a limitation. Is there any *other* use case for keeping COM objects (that are created by the core) around? If not, then like it or not, this is a problem for AMSI, not

[issue27417] Call CoInitializeEx on startup

Zachary Ware added the comment: What about instead of unconditionally calling CoInitializeEx in all cases, add a Py_EnsureCOM(flags) C API function? The flags param would be any flags that the caller must have, would default to 0, and would be combined with sys.coinit_flags before calling

[issue27417] Call CoInitializeEx on startup

Steve Dower added the comment: Mark: > CoInitialize will load a number of COM DLLs into the process, which isn't > free and will have some memory and performance costs for programs that don't > use COM. I see around 10 such DLLs loaded. Very good point. Most of those should already be loaded

[issue27417] Call CoInitializeEx on startup

Paul Moore added the comment: Hmm, this'll teach me to rely on my memory rather than checking :-) It seems to me that core code that needs COM can use it by wrapping the code in CoInitializeEx(sys.coinit_flags)...CoUninitialize(). That will either work fine (I don't know where you got the

[issue27417] Call CoInitializeEx on startup

Nikita Nemkin added the comment: COM should be initialized on demand by C modules that need it. They might need STA or MTA, it's their choice to make. Python core (ceval and builtins) doesn't need COM and shouldn't impose COM threading models on any threads it creates. Things like -X:STA are

[issue27417] Call CoInitializeEx on startup

Mark Hammond added the comment: I've a few reservations here: * CoInitialize will load a number of COM DLLs into the process, which isn't free and will have some memory and performance costs for programs that don't use COM. I see around 10 such DLLs loaded. * pythoncom uses sys.coinit_flags

[issue27417] Call CoInitializeEx on startup

Steve Dower added the comment: > pythoncom and comtypes use the value of sys.coinit_flags when imported Good to know. Assume we'll add that as well. Also, with respect to threading, we'd want to initialize on all new threads too. That will require a way to specify that a new thread should be

[issue27417] Call CoInitializeEx on startup

Steve Dower added the comment: I'm also okay to discuss whether MTA or STA should be the default, but I'll also be seeking advice from work colleagues on this who know COM really well. -- ___ Python tracker

[issue27417] Call CoInitializeEx on startup

Steve Dower added the comment: > But do I understand correctly that, if you implement this, there's no way for > me to select MTA? MTA would be the default, with no -X argument. But we could support a no-op "-X:MTA" as well. Because of the potential for use in security features, I don't want

[issue27417] Call CoInitializeEx on startup

Eryk Sun added the comment: pythoncom and comtypes use the value of sys.coinit_flags when imported, and otherwise default to calling CoInitializeEx(NULL, COINIT_APARTMENTTHREADED). Setting this value should ease problems, but something like -X:STA is still necessary. Note that the launcher

[issue27417] Call CoInitializeEx on startup

Tim Golden added the comment: As it happens, all the code I use which calls CoInitialise[Ex] does so with STA. But do I understand correctly that, if you implement this, there's no way for me to select MTA? If so I would consider that a major drawback. --

[issue27417] Call CoInitializeEx on startup

Steve Dower added the comment: > If it allowed user code to access COM without needing a 3rd party dependency, > I'd be +1, but I don't think that's being proposed here. It's a prerequisite to adding features to the stdlib that access COM (whether or not COM is directly exposed to the user).

[issue27417] Call CoInitializeEx on startup

Paul Moore added the comment: Things I know that call CoInitialize - pywin32/pythoncom and comtypes. I assume the proposal is to call CoInitializeEx in a way that won't break those? I'm not sure I see how this would affect the user (i.e. Python code). Brett mentions detecting the user's

[issue27417] Call CoInitializeEx on startup

Changes by Brett Cannon : -- nosy: +brett.cannon ___ Python tracker ___ ___

[issue27417] Call CoInitializeEx on startup

Steve Dower added the comment: It would enable wrapping up anything from this list too, and more: https://msdn.microsoft.com/en-us/library/windows/desktop/bb774328(v=vs.85).aspx Plenty of cool potential features in there :) -- ___ Python tracker

[issue27417] Call CoInitializeEx on startup

Brett Cannon added the comment: Steve has also told me this would enable querying the OS for what the default web browser is. -- ___ Python tracker ___

[issue27417] Call CoInitializeEx on startup

New submission from Steve Dower: I'd like to enable calling CoInitializeEx on Python startup for 3.6 (and into the future). See https://msdn.microsoft.com/en-us/library/windows/desktop/ms695279.aspx This would enable us to use more advanced Windows features within Python that require COM,