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 Albert.Zeyer
Recipients Albert.Zeyer, Seth.Troisi, eryksun, hitbox, joernheissler, nedbat, nneonneo, paul_ollis, rekcartgubnohtyp, sanjioh, serhiy.storchaka
Date 2020-01-15.22:54:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> I think it is worth pointing out that the semantics of 
>     f = ``open(fd, closefd=True)`` 
> are broken (IMHO) because an exception can result in an unreferenced file
> object that has taken over reponsibility for closing the fd, but it can
> also fail without creating the file object.

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`.

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.
Date User Action Args
2020-01-15 22:54:13Albert.Zeyersetrecipients: + Albert.Zeyer, nneonneo, nedbat, Seth.Troisi, serhiy.storchaka, paul_ollis, eryksun, sanjioh, joernheissler, hitbox, rekcartgubnohtyp
2020-01-15 22:54:13Albert.Zeyersetmessageid: <>
2020-01-15 22:54:13Albert.Zeyerlinkissue39318 messages
2020-01-15 22:54:13Albert.Zeyercreate