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 serhiy.storchaka
Recipients Oren Milman, geeknik, lemburg, pitrou, serhiy.storchaka, tim.peters, twouters, vstinner
Date 2017-10-07.18:18:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1507400297.89.0.213398074469.issue31165@psf.upfronthosting.co.za>
In-reply-to
Content
> What does "changing" mean exactly?

I'm not a GC expert. Maybe we should add a global flag that disable calling nontrivial destructors and set it in PyObject_GC_New(). The objects with nontrivial destructor should be added to the special queue and destroyed in "safe" place. There may be a problem with determining the "safe" place. I think that any Py_DECREF() is a "safe" place, and the eval loop is a "safe" place.

> What will be the effects on normal code?

I think this shouldn't affect Python code if perform deferred destroying in the eval loop. This can affect the execution of extensions if reference loops are created in C code. Some objects in loops can live longer that before.

> How do you know that it will not create new problems that didn't exist before?

I don't know. But we can try and see what is the result.
History
Date User Action Args
2017-10-07 18:18:17serhiy.storchakasetrecipients: + serhiy.storchaka, lemburg, tim.peters, twouters, pitrou, vstinner, Oren Milman, geeknik
2017-10-07 18:18:17serhiy.storchakasetmessageid: <1507400297.89.0.213398074469.issue31165@psf.upfronthosting.co.za>
2017-10-07 18:18:17serhiy.storchakalinkissue31165 messages
2017-10-07 18:18:17serhiy.storchakacreate