bpo-34066: Disabled interruption before SETUP_WITH and BEFORE_ASYNC_WITH.

[serhiy-storchaka]

This will prevent emitting a resource warning when the execution was
interrupted by Ctrl-C between calling open() and entering a 'with' block
in "with open()".

https://bugs.python.org/issue34066

[gpshead]

I believe this works. At least for the NEWS.d entry situation of with open(...) as f:. If the context manager's __enter__ is implemented in Python, evaluation of its own bytecode could process pending interrupts and lead to an exception being raised before it can setup its try: finally: handler (unless the __enter__ callable's very first opcode is SETUP_FINALLY?).

_io.open's __enter__ is implemented in C so it should be safe. I looped in @ncoghlan for a second pair of eyes on this.

[ncoghlan]

Aye, this looks good to me. It would still be nice to come up with a more systematic solution, but in the meantime, we may as well handle this specific case.

[miss-islington]

Thanks @serhiy-storchaka for the PR, and @ncoghlan for merging it 🌮🎉.. I'm working now to backport this PR to: 3.6, 3.7.
🐍🍒⛏🤖

[bedevere-bot]

GH-8197 is a backport of this pull request to the 3.7 branch.

[miss-islington]

Sorry, @serhiy-storchaka and @ncoghlan, I could not cleanly backport this to 3.6 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker 3f4d90d4d72921f16babd3f52d7df804916af224 3.6

[bedevere-bot]

GH-8198 is a backport of this pull request to the 3.6 branch.

[markshannon]

I'm not keen on this change.
IMO, the proper general fix is to document that firing interrupts at your program is likely to cause problems, not adding more and more corner cases.

For the specific case of open() the problem is that the resource to be freed is acquired not in the __enter__ method, but in open(). Adding an Opener object is one possible fix.

with Opener(filename):
    ...

Opener.__enter__() would actually open the file.

[ncoghlan]

Adding Opener still doesn't actually fix the problem in the general case: https://bugs.python.org/issue29988

So for now, we're only playing the statistical game of improving people's odds of avoiding poorly timed signals, without addressing the underlying flaws in the signal handling architecture. Longer term, it definitely makes sense to move signal checks to returning from functions and jumping back in loops, and then working out some way to exempt __enter__ and __exit__ methods from those general rules (while still not making them uninterruptible)