> > 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 entirely free and so it's the right time to add new complications.

My point with that is that pythonwin is a GUI app rarely started by the command-line. It isn't that adding the cmdline support is difficult, more that it's difficult for users to specify it. This will be true for any GUI installed into the start menu (eg, idle)

> Nikita:
> > COM should be initialized on demand by C modules that need it. They might need STA or
> > MTA, it's their choice to make.

> And if the C module is the core interpreter (see issue26137 for an example of where
> this would be necessary)? If we require user code to initialize COM, this whole
> proposal is moot as that is the current state of the world and it does not require
> any changes to achieve.

I'd be surprised if issue26137 ended up unconditionally doing a malware scan on everything Python ever executes. Thus, I don't see why "I'd like to enable calling CoInitializeEx on Python startup for 3.6" is necessary - just attempting to initialize it immediately before that feature is invoked would be fine and may sidestep the entire issue. Instead of command-line flags to control COM initialization we should add new flags to disable these new features that require COM (and thus also implicitly control whether COM is initialized or not.)

IOW, I think it makes sense for the core to initialize COM immediately before it needs to use COM, under the assumption that executing "python" or "python myscript.py" isn't going to need to do that by default. I think initializing COM by default at process startup on the off-chance that some COM-using feature will be invoked is more problematic.