Author nneonneo
Recipients Albert.Zeyer, Seth.Troisi, eryksun, hitbox, joernheissler, nedbat, nneonneo, sanjioh, serhiy.storchaka
Date 2020-01-15.10:30:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1579084240.25.0.045989438861.issue39318@roundup.psfhosted.org>
In-reply-to
Content
Could this be solvable if `closefd` were a writable attribute? Then we could do

    file = None
    try:
        file = io.open(fd, ..., closefd=False)
        file.closefd = True
    except:
        if file and not file.closefd:
            os.close(fd)
        raise

I believe this should be bulletproof - a KeyboardInterrupt can happen anywhere in the `try` and we will not leak or double-close. Either file.closefd is set, in which case `file` owns the fd and will close it eventually, or file.closefd is not set in which case the fd needs to be manually closed, or file doesn't exist (exception thrown in io.open or while assigning file), in which case the fd still needs to be manually closed.

Of course, this can leak if a KeyboardInterrupt lands in the `except` - but that's not something we can meaningfully deal with. The important thing is that this shouldn't double-close if I analyzed it correctly.

This is a somewhat annoying pattern, though. I wonder if there's a nicer way to implement it so we don't end up with this kind of boilerplate everywhere.
History
Date User Action Args
2020-01-15 10:30:40nneonneosetrecipients: + nneonneo, nedbat, Seth.Troisi, Albert.Zeyer, serhiy.storchaka, eryksun, sanjioh, joernheissler, hitbox
2020-01-15 10:30:40nneonneosetmessageid: <1579084240.25.0.045989438861.issue39318@roundup.psfhosted.org>
2020-01-15 10:30:40nneonneolinkissue39318 messages
2020-01-15 10:30:39nneonneocreate