Albert Zeyer <> added the comment:

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


Python tracker <>
Python-bugs-list mailing list

Reply via email to