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 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 <>
Could this be solvable if `closefd` were a writable attribute? Then we could do

    file = None
        file =, ..., closefd=False)
        file.closefd = True
        if file and not file.closefd:

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 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.
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: <>
2020-01-15 10:30:40nneonneolinkissue39318 messages
2020-01-15 10:30:39nneonneocreate