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 aeros
Recipients aeros, asvetlov, petr.viktorin, yselivanov
Date 2020-06-04.23:36:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1591313764.27.0.932240187796.issue40802@roundup.psfhosted.org>
In-reply-to
Content
The main issue is that shutdown_default_executor() (or something that does the same thing) is necessary to ensure the resources of the event loop's ThreadPoolExecutor are finalized in a safe manner. Otherwise, it frequently results in dangling threads when run_in_executor() is used with the default executor, and was regularly doing so in the buildbots. So, I think this is a case where we ultimately have to break backwards compatibility in an upcoming version to fix a bug.

Also, the implementation of shutdown_default_executor() is fairly straightforward, and as far as I'm aware it's not incompatible with any of the listed projects that would need to implement it for 3.9. While inconvenient, I don't think the burden to address the compatibility break is at all high in this case.

> Since asyncio is no longer provisional, should it break backwards compatibility with just a What's New entry?

Do you have an alternative suggestion? Personally, I don't think a deprecation warning (or other) would make much sense here since it would be effectively leaving a resource leak bug as long as it isn't implemented.
History
Date User Action Args
2020-06-04 23:36:04aerossetrecipients: + aeros, petr.viktorin, asvetlov, yselivanov
2020-06-04 23:36:04aerossetmessageid: <1591313764.27.0.932240187796.issue40802@roundup.psfhosted.org>
2020-06-04 23:36:04aeroslinkissue40802 messages
2020-06-04 23:36:04aeroscreate