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.16:27:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1467304044.17.0.773510185629.issue27417@psf.upfronthosting.co.za>
In-reply-to
Content
> 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 for a general "initialise COM" proposal.

Basically, I'm saying that it's only worth splitting this proposal out from the AMSI one if there's a benefit (to offset the costs) for code other than AMSI. And there seems to be no such use case.
History
Date User Action Args
2016-06-30 16:27:24paul.mooresetrecipients: + paul.moore, mhammond, brett.cannon, tim.golden, zach.ware, eryksun, steve.dower, nnemkin
2016-06-30 16:27:24paul.mooresetmessageid: <1467304044.17.0.773510185629.issue27417@psf.upfronthosting.co.za>
2016-06-30 16:27:24paul.moorelinkissue27417 messages
2016-06-30 16:27:24paul.moorecreate