homepage

Martin raises an interesting point - the cases where ResourceWarning is likely to be appropriate are going to be those where the frame has been suspended inside a with statement or a try/finally statement.
However, we don't currently track those at runtime or at compile time in any way - they're implicit in the state of the frame stack.
That doesn't mean we *couldn't* track them though, and I think co_lnotab provides a hint as to how we could do it with minimal runtime overhead: add a new co_cleanup data table to code objects that provides efficiently packed storage for a sequence of "setup/cleanup" bytecode offset 2-tuples.
All code objects would gain an additional pointer, and those that used with and try/finally would get fractionally larger than that, but frame objects would remain the same size they are today.
Glossing over the complexities of large bytecode offsets (ala co_lnotab), consider:
>>> def g_with():
... with ...:
... pass
... 
>>> dis.dis(g_with)
 2 0 LOAD_CONST 1 (Ellipsis)
 3 SETUP_WITH 5 (to 11)
 6 POP_TOP
 3 7 POP_BLOCK
 8 LOAD_CONST 0 (None)
 >> 11 WITH_CLEANUP_START
 12 WITH_CLEANUP_FINISH
 13 END_FINALLY
 14 LOAD_CONST 0 (None)
 17 RETURN_VALUE
Here, co_cleanup would include a single 2-tuple with '0x03' as an absolute offset (for the setup) and '0x08' as a relative offset (for the cleanup). If '(f_lasti - 0x03) < 0x08' then __del__ on a generator-iterator or coroutine would raise ResourceWarning.
>>> def g_finally():
... try:
... pass
... finally:
... pass
... 
>>> dis.dis(g_finally)
 2 0 SETUP_FINALLY 4 (to 7)
 3 3 POP_BLOCK
 4 LOAD_CONST 0 (None)
 5 >> 7 END_FINALLY
 8 LOAD_CONST 0 (None)
 11 RETURN_VALUE
Here, co_cleanup would include a single 2-tuple with '0x00' as an absolute offset (for the setup) and '0x07' as a relative offset (for the cleanup). If '(f_lasti - 0x00) < 0x07' then __del__ on a generator-iterator or coroutine would raise ResourceWarning.
The key is that *only* __del__ would get slower (not explicit close() calls), and it would only get slower in cases where the frame was still suspended *and* co_cleanup was populated.