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 ncoghlan
Recipients jwilk, ncoghlan, rhettinger
Date 2018-07-20.15:17:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
It's still the same problem - the underlying issue is that the with statement machinery doesn't currently mask signals in the main thread while __enter__ and __exit__ are running, so __enter__ and __exit__ methods written in Python are also at risk of being interrupted at an inopportune point.

This means that even "with closing(open('filename')) as f: ..." is more at risk of leaving the file open until __del__ cleans it up than the version that calls open() directly.

So if this a concern that an application needs to worry about, then it currently needs to adopt a more complicated execution structure where:

1. The main thread launches a subthread that actually does all the work.
2. The main thread immediately drops into "active_thread.join()" (which can be interrupted by Ctrl-C)

Unfortunately, this scheme *doesn't* work for applications where the application itself needs to detect and handling signals other than Ctrl-C.
Date User Action Args
2018-07-20 15:17:51ncoghlansetrecipients: + ncoghlan, rhettinger, jwilk
2018-07-20 15:17:51ncoghlansetmessageid: <>
2018-07-20 15:17:51ncoghlanlinkissue34157 messages
2018-07-20 15:17:51ncoghlancreate