Albert Zeyer <alb...@googlemail.com> 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 <rep...@bugs.python.org> <https://bugs.python.org/issue39318> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
