Guido van Rossum wrote:
>> @with_template
>> def closing(obj):
>> try:
>> yield obj
>> finally:
>> obj.close()
>>
> I just realized this has a race condition. The bytecode for the
> expression closing(open("...")) must necessarily contain a bytecode
> that calls open() followed by another bytecode that calls closing().
This is not a convincing point. That race condition always existed,
e.g. in the traditional
f = open(filename)
try:
process(f)
finally:
f.close()
as you could always get an async exception between open returns and
f is assigned. This isn't much of an issue, since CPython would always
release the file immediately as the stack frame is cleared due to
the exception.
I think would should explicitly weaken our guarantees for
"asynchronous" exceptions (of which we currently only have
KeyboardInterrupt). The PEP should point out that an async
exception between the beginning of the with statement and
the assignment to the variable may or may not cause __exit__
to be called (depending on how far you are into __enter__)
Regards,
Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4