Author ncoghlan
Recipients brian.curtin, dabrahams, eric.smith, ncoghlan, pitrou, tim.golden
Date 2012-03-11.02:21:03
SpamBayes Score 2.29332e-11
Marked as misclassified No
Message-id <1331432465.25.0.403941847199.issue14243@psf.upfronthosting.co.za>
In-reply-to
Content
The whole point of close() methods is to offer deterministic resource management to applications that need it. Pointing out to applications when they're relying on CPython's refcounting for prompt resource cleanup is why many of the standard types now trigger ResourceWarning for any application that relies on the GC to clean up such external resources in __del__.

So, no, we're not going to back away from the explicit guarantee in the NamedTemporaryFile docs: "If delete is true (the default), the file is deleted as soon as it is closed." (Especially since doing so would also breach backward compatibility guarantees)

However, you're right that the exclusive read lock in the current implementation makes the default behaviour of NamedTemporaryFile significantly less useful on Windows than it is on POSIX systems, so the implementation should be changed to behave more like the POSIX variant.
History
Date User Action Args
2012-03-11 02:21:05ncoghlansetrecipients: + ncoghlan, pitrou, eric.smith, tim.golden, brian.curtin, dabrahams
2012-03-11 02:21:05ncoghlansetmessageid: <1331432465.25.0.403941847199.issue14243@psf.upfronthosting.co.za>
2012-03-11 02:21:04ncoghlanlinkissue14243 messages
2012-03-11 02:21:03ncoghlancreate