This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author paul.moore
Recipients brett.cannon, eryksun, mhammond, nnemkin, paul.moore, steve.dower, tim.golden, zach.ware
Date 2016-06-30.10:04:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1467281052.99.0.788298344339.issue27417@psf.upfronthosting.co.za>
In-reply-to
Content
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 idea that CoInitializeEx can only be called once per thread - AFAICT the the documentation you linked to clearly states that's not the case) or it will fail because someone else has initialised the thread with an incompatible model. Either try the other model (if you don't actually care) or report the issue and stop - it's the user's code that is relying on conflicting functions, so let the user decide how to deal with it.

Do you have a use case in mind where something like the above wouldn't work?

BTW, I agree that AMSI sounds like a very weird thing to want to add to the Python interpreter - maybe it might make sense to have a special build "checking" interpreter that could be used in appropriate circumstances, but I'd be very uncomfortable adding something like that to the core binary or making it "enabled by default and not be able to be disabled". So that's not a good motivating use case for me...
History
Date User Action Args
2016-06-30 10:04:13paul.mooresetrecipients: + paul.moore, mhammond, brett.cannon, tim.golden, zach.ware, eryksun, steve.dower, nnemkin
2016-06-30 10:04:12paul.mooresetmessageid: <1467281052.99.0.788298344339.issue27417@psf.upfronthosting.co.za>
2016-06-30 10:04:12paul.moorelinkissue27417 messages
2016-06-30 10:04:12paul.moorecreate