[issue14243] NamedTemporaryFile unusable under Windows

R. David Murray added the comment: See issue 14514 for an alternate proposal to solve this. I did search before I opened that issue, but search is currently somewhat broken and I did not find this issue. I'm not marking it as a dup because my proposal is really a new feature. -- no

[issue14243] NamedTemporaryFile unusable under Windows

Changes by Jason R. Coombs : -- nosy: +jason.coombs ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue14243] NamedTemporaryFile unusable under Windows

Changes by Éric Araujo : -- nosy: +eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue14243] NamedTemporaryFile unusable under Windows

Dave Abrahams added the comment: Nick, not to belabor this, but I guess you don't understand the use-case in question very well, or you'd see that delete=False doesn't cover it. The use case is this: I have to write a test for a function that takes a filename as a parameter and opens and read

[issue14243] NamedTemporaryFile unusable under Windows

Nick Coghlan added the comment: Dave, decoupling the lifecycle of the created file from the object that created it is exactly what delete=False already covers. The complicated dance in NamedTemporaryFile is only to make *__del__* work a bit more reliably during process shutdown (due to some

[issue14243] NamedTemporaryFile unusable under Windows

Dave Abrahams added the comment: If file.close() "offers deterministic resource management," then you have to consider the file's open/closed state to be a resource separate from its existence. A NamedTemporaryFile whose close() deterministically managed the open/closed state but not the exi

[issue14243] NamedTemporaryFile unusable under Windows

Nick Coghlan added the comment: 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 R

[issue14243] NamedTemporaryFile unusable under Windows

Dave Abrahams added the comment: I disagree that it's unacceptable for close() and __del__() to behave differently. The acceptable difference would be that __del__() closes (if necessary) /and/ deletes the file on disk, while close() merely closes the file. If you can in fact "change the way

[issue14243] NamedTemporaryFile unusable under Windows

Changes by Antoine Pitrou : -- nosy: +brian.curtin, tim.golden ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14243] NamedTemporaryFile unusable under Windows

Antoine Pitrou added the comment: > OTOH, if the proposal is merely to change the way the file is opened > on Windows so that it can be opened again without closing it first, > that sounds fine. That would be my proposal. It probably needs getting rid of O_TEMPORARY, exposing CreateFile and _op

[issue14243] NamedTemporaryFile unusable under Windows

Nick Coghlan added the comment: What's the proposal here? If delete is True, close() must delete the file. It is not acceptable for close() and __del__() to behave differently. OTOH, if the proposal is merely to change the way the file is opened on Windows so that it can be opened again witho

[issue14243] NamedTemporaryFile unusable under Windows

Antoine Pitrou added the comment: This is quite silly indeed, and is due to the use of O_TEMPORARY in the file creation flags. -- nosy: +ncoghlan, pitrou title: NamedTemporaryFile usability request -> NamedTemporaryFile unusable under Windows type: -> behavior versions: +Python 3.2,