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 paul_ollis
Recipients Albert.Zeyer, Seth.Troisi, eryksun, hitbox, joernheissler, nedbat, nneonneo, paul_ollis, rekcartgubnohtyp, sanjioh, serhiy.storchaka
Date 2020-01-16.09:27:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> I thought that if this raises a (normal) exception, it always means that it
> did not have overtaken the `fd`, i.e. never results in an unreferenced file
> object which has taken ownership of `fd`.

The current CPython implementation does not guard against this happening. Some
incorrect combinations of arguments will definitely cause the problem. It is
also possible that it could occur under other circumstances.

> It this is not true right now, you are right that this is problematic. But
> this should be simple to fix on the CPython side, right? I.e. to make sure
> whenever some exception is raised here, even if some temporary file object
> already was constructed, it will not close `fd`. It should be consistent in
> this behavior, otherwise indeed, the semantics are broken.

I agree. I think it should be fairly simple to fix for CPython.
Date User Action Args
2020-01-16 09:27:07paul_ollissetrecipients: + paul_ollis, nneonneo, nedbat, Seth.Troisi, Albert.Zeyer, serhiy.storchaka, eryksun, sanjioh, joernheissler, hitbox, rekcartgubnohtyp
2020-01-16 09:27:07paul_ollissetmessageid: <>
2020-01-16 09:27:07paul_ollislinkissue39318 messages
2020-01-16 09:27:06paul_olliscreate