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 steve.dower
Recipients Carl Osterwisch, Gabi.Davar, John Florian, chary314, dabrahams, davide.rizzo, dlenski, eric.araujo, eric.smith, eryksun, ethan smith, ethan.furman, ev2geny, jaraco, jwilk, martin.panter, ncoghlan, njs, paul.moore, piotr.dobrogost, pitrou, r.david.murray, sbt, steve.dower, tim.golden, zach.ware
Date 2021-04-12.19:45:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1618256751.66.0.335834297886.issue14243@roundup.psfhosted.org>
In-reply-to
Content
O_TEMPORARY is clearly not the right option here, and we should just move the unlink call into __exit__ and attempt it even if close() has been called.

Windows's "delete on close" functionality is great, but if you haven't designed for its semantics, it's unusable. And this library is not designed for it, so users can't rely on the native functionality.

So we stop passing the O_TEMPORARY flag. If __enter__() is called, close() closes the file but doesn't delete anything, and __exit__() closes the file (if open) and deletes it (even if it wasn't open). If there is no __enter__(), close() also deletes the file.
History
Date User Action Args
2021-04-12 19:45:51steve.dowersetrecipients: + steve.dower, paul.moore, jaraco, ncoghlan, pitrou, eric.smith, tim.golden, jwilk, eric.araujo, r.david.murray, njs, dabrahams, ethan.furman, davide.rizzo, sbt, Gabi.Davar, martin.panter, piotr.dobrogost, zach.ware, dlenski, eryksun, Carl Osterwisch, ethan smith, John Florian, ev2geny, chary314
2021-04-12 19:45:51steve.dowersetmessageid: <1618256751.66.0.335834297886.issue14243@roundup.psfhosted.org>
2021-04-12 19:45:51steve.dowerlinkissue14243 messages
2021-04-12 19:45:51steve.dowercreate