[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Inada Naoki added the comment: +1 to Eryk. > Hence my newbie questions are: 1) What problem are you trying to solve by this "unlinking trick"? Same to TempoaryFile in Unix. 2) Do we need to have a separate issue raised for this problem? I don't think so. We didn't unlink because wi didn't

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Evgeny added the comment: Eryk, I agree, that implementing TemporaryFile() in Windows goes hand in hand with the decision to stop using O_TEMPORARY in NamedTemporaryFile() The only thing I want to point out is that your suggestion also includes this "unlinking trick" (sorry, may be there

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Eryk Sun added the comment: > you are proposing some trick with first unlinking the file and > then employing it as a temporary file using previously known fd. It doesn't need to unlink the file to make it anonymous. I included that to highlight that it's possible. The details can be

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Evgeny added the comment: > Eryk Sun added the comment: > Just implement a separate function for TemporaryFile() instead of aliasing it > to NamedTemporaryFile(). See msg390814. Eryk, forgive my ignorance, but aren't in your msg390814 you are proposing yet another enhancement (separate

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Paul Moore added the comment: Eryk, thank you for clarifying. I apologise - I got bogged down somewhere in the middle of the discussion on reimplementing bits of the CRT (your posts are so information-dense that my usual habit of skimming breaks down - that's not a complaint, though!)

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Eryk Sun added the comment: > Does it mean, that your suggestion to leave the O_TEMPORARY for > TemporaryFile means, that NamedTemporaryFile needs to have a > mechanism to know whether it was called as a TemporaryFile Just implement a separate function for TemporaryFile() instead of

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Evgeny added the comment: >Paul Moore added the comment: >Evgeny, would you be willing to update your PR (including adding the docs >change, and tests to catch as many edge cases as you can think up) to match >this behaviour? Paul, thank you for moving this forward. I will give it a try.

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Change by John Florian : -- nosy: -John Florian ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Evgeny added the comment: >Eryk Sun added the comment: >I replied twice that I thought using the CM exit instead of O_TEMPORARY is >okay for NamedTemporaryFile() -- but only if a separate implementation of >TemporaryFile() that uses O_TEMPORARY is added at the same time. I want

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Eryk Sun added the comment: > deleting on CM exit when used as a CM, and no change in behaviour > otherwise (me, Zachary, Ethan, Jason and Steve). Steve also wants > O_TEMPORARY to be removed, which doesn't seem controversial among > this group of people. Removing O_TEMPORARY is not an

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Paul Moore added the comment: Looking at the various comments, I think we have 5 votes for deleting on CM exit when used as a CM, and no change in behaviour otherwise (me, Zachary, Ethan, Jason and Steve). Steve also wants O_TEMPORARY to be removed, which doesn't seem controversial among

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Zachary Ware added the comment: > if NamedTemporaryFile is used as a context manager, the file is closed *on > context manager exit* and *not* when the file is closed. +1 -- ___ Python tracker

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Paul Moore added the comment: To be explicit, I'm +1 on breaking backward compatibility in the minor form described by Ethan: if NamedTemporaryFile is used as a context manager, the file is closed *on context manager exit* and *not* when the file is closed. Breaking compatibility is allowed

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Evgeny added the comment: On Mon, Apr 12, 2021 at 12:51 AM Jason R. Coombs wrote: > Jason R. Coombs added the comment: > At least I and Ethan and Martin have expressed a desire for the default, > preferred usage work well in a portable environment. Requiring > `delete_on_close=False`

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Evgeny added the comment: Dear all, thank you very much for the discussion, I will just try to summarize the results of it. In my PR I used solution, proposed by Eryk. My solution involves introduction of the extra flag delete_on_close and making sure, that new situation is fully

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Eryk Sun added the comment: > 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

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Ethan Furman added the comment: Hey, you agree with me now, so it's not noise. ;-) -- ___ Python tracker ___ ___ Python-bugs-list

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Paul Moore added the comment: Sorry - I'm maybe making an unwarranted assumption. If simply removing "delete on close" behaviour in the CM case is acceptable, then I'm 100% in favour of that. I'd assumed that it was somehow unacceptable, but you're right, and it's not clear if Eryk is

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Ethan Furman added the comment: Paul, If "rescuing" (i.e. "fixing" ;) NamedTemporaryFile was arduous, complicated, or had serious backwards-compatibility issues then I would completely agree with you. However, the fix is simple, the only backwards-compatible issue is the file would still

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Paul Moore added the comment: There's a lot of technical discussion of implementation details here, but not much about use cases. IMO, what's more important is whether NamedTemporaryFile is *useful* to people, and what they want to use it *for*. Working out how to implement it can come

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Steve Dower added the comment: 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

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Ethan Furman added the comment: Eryk, I'm not sure if you are agreeing or disagreeing with me. :) On Windows it sounds like O_TEMPORARY buys us guaranteed file deletion, but costs us easy sharing of file resources and a difference in semantics between Windows and non-Windows. Is the

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Eryk Sun added the comment: > My opinion is that no extra flags are necessary. The default of > deleting on close is fine, unless a context manager is active -- in > which case delete on CM exit. There is a use case of needing to let another thread or process open the temporary file while

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Ethan Furman added the comment: On 4/11/2021 3:51 PM, Jason R. Coombs wrote: > Jason R. Coombs added the comment: > > At least I and Ethan and Martin have expressed a desire for the default, preferred usage work well in a portable environment. Requiring `delete_on_close=False` violates

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Jason R. Coombs added the comment: At least I and Ethan and Martin have expressed a desire for the default, preferred usage work well in a portable environment. Requiring `delete_on_close=False` violates that expectation. How about something like this instead: - Add an `delete_when=None`,

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Evgeny added the comment: Dear all, how can we realistically move this forward? This issue is 9 years old by now. Everybody from the discussion agrees, this is an issue. There were several proposals made, all of them slightly different. 7 months ago I have implemented solution, pretty much

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Ethan Furman added the comment: I think the best solution, albeit slightly backwards incompatible, is to change NamedTemporaryFile such that if (and only if) it is being used as a context manager, the underlying file is not closed until the context manager ends. This should be the default

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Change by Evgeny : -- keywords: +patch pull_requests: +22618 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/22431 ___ Python tracker

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Evgeny added the comment: Hello, this is to let you know, that I have created a pull request for this issue https://github.com/python/cpython/pull/22431 I am not really an experienced programmer, but I will give it a try -- nosy: +ev2geny ___

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Eryk Sun added the comment: > We'd CreateFile the file and then immediately pass it to > _open_osfhandle Unlike _wopen, _open_osfhandle doesn't truncate Ctrl+Z (0x1A) from the last byte when the flags value contains _O_TEXT | _O_RDWR. _wopen implements this to allow appending data in text

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Steve Dower added the comment: We'd CreateFile the file and then immediately pass it to _open_osfhandle, which would keep the semantics the same apart from the share flags. I'm not entirely against getting rid of O_TEXT support, but haven't taken the time to think through the implications.

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Eryk Sun added the comment: > we'd have to reimplement the UCRT function using the system API. Could the implementation drop support for os.O_TEXT? I think Python 3 should have removed both os.O_TEXT and os.O_BINARY. 3.x has no need for the C runtime's ANSI text mode, with its Ctrl+Z

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Steve Dower added the comment: The comment you quoted was referring to the NamedTemporaryFile(do_not_delete) flag. Yes, we'd have to reimplement the UCRT function using the system API. Ultimately, it's not a great compatibility layer if you want to match POSIX semantics and not just the C

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Eryk Sun added the comment: > Nothing preventing someone from contributing the flag on open as well. To be clear, supporting delete-access sharing would require re-implementing C _wopen in terms of CreateFileW, _open_osfhandle, etc. It could be implemented as _Py_wopen in

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Steve Dower added the comment: Issue41490 can also be fixed by using FILE_SHARE_DELETE on all opened files (and that's a release blocker, so we need to fix it somehow), and if DeleteFile has been updated as you suggest then it might even help with the "pip replacing its own script

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Eryk Sun added the comment: > Why do we need to use this O_TEMPORARY flag at all? Using the O_TEMPORARY flag isn't necessary, but it's usually preferred because it ensures the file gets deleted even if the process is terminated abruptly. However, it opens the file with delete access, and

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Chary Chary added the comment: I am not sure, this is the correct place to ask this "educational" question, but I will do this any way: where is this O_TEMPORARY flag defined? if I looks at

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Chary Chary added the comment: Why do we need to use this O_TEMPORARY flag at all? I understand that we are using OS functionality, available on Windows, rather than implementing it in Python. But why doing this, if we already do this for none-nt systems in Python any way? Doesn't it just

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Eryk Sun added the comment: > For this case, I think the best thing we can probably do is change the > default share mode for _all_ opens to include FILE_SHARE_DELETE. The C runtime doesn't provide a way to share delete access, except for the O_TEMPORARY flag, so Python would have to

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Chary Chary added the comment: Steve Dower, thanks for looking at this. After reading the thread from my amature point of view I kind of liked suggestion of Daniel Lenski to replace the binary delete argument of the current NamedTemporaryFile implementation with finer-grained options

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Steve Dower added the comment: In general, if a bug here appears to be inactive, it's probably waiting on someone to volunteer to move it forward. Often merely posting to a thread is enough. For this case, I think the best thing we can probably do is change the default share mode for _all_

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Chary Chary added the comment: Dear all, are there any plans to move this quite old issue forward? I stumbled across this issue, because I found that at the moment there is no out of the box solution to use  tempfile.NamedTemporaryFile in Windows in such scenario (which is often used in unit

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Change by Ethan Smith : -- nosy: +Ethan Smith ___ Python tracker ___ ___ Python-bugs-list

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Changes by Nathaniel Smith : -- nosy: +njs ___ Python tracker ___ ___ Python-bugs-list

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Eryk Sun added the comment: Richard wrote: > while a handle is open with share mode X, you can only reopen > the file if you also use share mode X To clarify, the share mode is not a property of a handle. It's a property of a File object. A handle is a generic reference to any kind of kernel

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Eryk Sun added the comment: Nick wrote: > 1. Open the file in the current process > 2. Write content to the file > 3*. Close the file in the current process In step 1, do you mean calling NamedTemporaryFile with delete=False? In that case there's no immediate problem with opening the file

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Nick Coghlan added the comment: John: I don't think it would be clutter to have an explicit reminder about that point in the NamedTemporaryFile documentation, so feel free to file a separate enhancement issue for it. -- ___ Python tracker

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

John Florian added the comment: Okay Nick. Thanks for the detailed info. I suspected buffering was a factor, but wasn't certain. Would it be worthwhile pursuing a note in the docs or would that constitute clutter over what should be a standard assumption? I was thrown off course for all the

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Nick Coghlan added the comment: John, your problem sounds different - if you're opening the files in binary mode, then you'll be getting a default buffer that's probably 4k or 8k in size, so if you're writing less content than that, the subprocess won't see anything until you explicitly

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Changes by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Changes by Jakub Wilk : -- nosy: +jwilk ___ Python tracker ___ ___ Python-bugs-list mailing

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

John Florian added the comment: I just stumbled onto this though I'm not writing for Windows. Instead, I'm on Fedora 25 with Python 3.5.2 and I went nearly crazy tracing down what seemed to be inconsistent behavior. My use case has Python using NamedTemporaryFile(delete=True) in a CM to

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Changes by Paul Moore p.f.mo...@gmail.com: -- nosy: +paul.moore ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14243 ___ ___ Python-bugs-list

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Changes by Martin Panter vadmium...@gmail.com: -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14243 ___ ___ Python-bugs-list

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Mark Lawrence added the comment: This is one of several Windows file related issues, see also #12939, #21859, #15244 and possibly others. How can we take this forward? If it's of any use I can help with testing as I've a new Windows 8.1 HP laptop with 8G of memory. -- nosy:

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Changes by Gabi Davar grizzly@gmail.com: -- nosy: +Gabi.Davar ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14243 ___ ___ Python-bugs-list

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Piotr Dobrogost added the comment: @sbt Thanks for info. Also you mentioned looking at c:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/crt/src/open.c What version of Visual Studio/SDK this file is available in? Also I'd like to point out that this problem came up at Stack Overflow in

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Piotr Dobrogost added the comment: @sbt (...) and it seems that on Windows open() is more or less implemented as a wrapper of sopen(..., ..., SH_DENYNO, ...). So the only reason that trying to reopen a NamedTemporaryFile fails on Windows is because when we reopen we need to use

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Richard Oudkerk added the comment: Sorry, I was not very clear. If you use the O_TEMPORARY flag with open() to get a file handle, then the share mode used with the underlying CreateFile() function is X = FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE whereas, if you don't use

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Changes by Piotr Dobrogost p...@bugs.python.dobrogost.net: -- nosy: +piotr.dobrogost ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14243 ___ ___

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Richard Oudkerk shibt...@gmail.com added the comment: I have opened Issue #15244 with a patch to add a share module to the stdlib. After monkey patching builtins.open(), io.open() and os.open() to be equivalents using FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, the regression test

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Tim Golden m...@timgolden.me.uk added the comment: On 30/06/2012 06:45, Daniel Lenski wrote: My preferred solution would be to replace the binary delete argument of the current NamedTemporaryFile implementation with finer-grained options: delete=False # don't delete

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Richard Oudkerk shibt...@gmail.com added the comment: I wrote in an earlier message that a file opened with O_TEMPORARY must be reopened with O_TEMPORARY. This is not quite accurate. Using O_TEMPORARY causes the FILE_SHARE_DELETE sharing mode to be used, and a file currently opened with

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Daniel Lenski dlen...@gmail.com added the comment: Richard, I think the problem with this is that it spreads the non-portable or OS-dependent parts of the code over several places rather than concentrating them all in one place. After close_without_unlink(), what would happen when the context

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Richard Oudkerk shibt...@gmail.com added the comment: The webpage http://msdn.microsoft.com/en-us/library/aa273350(v=vs.60).aspx describes the sopen() function which is like open() but has an extra shflag parameter for specifying the sharing allowed. If sopen() and the associated

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Antoine Pitrou pit...@free.fr added the comment: If sopen() and the associated constants SH_DENYRD, SH_DENYWR, SH_DENYRW and SH_DENYNO were exposed in the os module, then maybe tempfile could use os.sopen() on Windows instead of os.open() to allow the file to be reopened without closing.

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Tim Golden m...@timgolden.me.uk added the comment: On 01/07/2012 21:37, Antoine Pitrou wrote: Antoine Pitrou pit...@free.fr added the comment: If sopen() and the associated constants SH_DENYRD, SH_DENYWR, SH_DENYRW and SH_DENYNO were exposed in the os module, then maybe tempfile could use

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Richard Oudkerk shibt...@gmail.com added the comment: Agreed. Richard: do you have time to put something together? I'm happy to try if you don't. I'm looking into it. Unfortunately, it seems that you need to use non-default flags when reopening a shared file. Eg, if the file is currently

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Richard Oudkerk shibt...@gmail.com added the comment: I checked the source in c:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/crt/src/open.c and it seems that on Windows open() is more or less implemented as a wrapper of sopen(..., ..., SH_DENYNO, ...). So the only reason that

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Nick Coghlan ncogh...@gmail.com added the comment: Alternatively, perhaps it would make sense to have a reopen() method on file objects that covers the necessary dance to reopen with the correct flags? That would solve more problems than just this one (possibly including making it possible to

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Davide Rizzo sor...@gmail.com added the comment: Daniel, Nick, shouldn't the context manager yield f within a with block? -- nosy: +davide.rizzo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14243

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Richard Oudkerk shibt...@gmail.com added the comment: Rather than add a NamedTemporaryFile.delete_after() classmethod, would it not be simpler to just add a close_without_unlink() method to NamedTemporaryFile? with NamedTemporaryFile() as f: write to f

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Daniel Lenski dlen...@gmail.com added the comment: Davide, the @contextlib.contextmanager decorator effectively wraps the yield statement in the necessary glue so that everything prior to the yield statement occurs in the __enter__() method of the contextmanager, while everything subsequent

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Changes by Daniel Lenski dlen...@gmail.com: -- nosy: +dlenski ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14243 ___ ___ Python-bugs-list mailing

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Tim Golden m...@timgolden.me.uk added the comment: Daniel. If you have any interest in this issue, would you mind summarising the state of affairs, please? I have no direct interest in the result but I'm happy to commit a patch or even to work one up if somone can come up with a single,

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Daniel Lenski dlen...@gmail.com added the comment: Tim Golden, My preferred solution would be to replace the binary delete argument of the current NamedTemporaryFile implementation with finer-grained options: delete=False # don't delete delete=True # delete after file

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

R. David Murray rdmur...@bitdance.com added the comment: delete_after what? I know it is somewhat implicit in the fact that it is a context manager call, but that is not the only context the method name will be seen in. (eg: 'dir' list of methods, doc index, etc). Even as a context manager

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

R. David Murray rdmur...@bitdance.com added the comment: By the way, I still think it would be nicer just to have the context manager work as expected with delete=True (ie: doesn't delete until the end of the context manager, whether the file is closed or not). I'm OK with being voted down

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Antoine Pitrou pit...@free.fr added the comment: By the way, I still think it would be nicer just to have the context manager work as expected with delete=True (ie: doesn't delete until the end of the context manager, whether the file is closed or not). I'm OK with being voted down on that,

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Jason R. Coombs jar...@jaraco.com added the comment: I agree. If the primary usage of the class does not work well on Windows, developers will continue to write code using the primary usage because it works on their unix system, and it will continue to cause failures when run on windows.

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

R. David Murray rdmur...@bitdance.com added the comment: Well, fixing NamedTemporaryFile in either of the ways we've discussed isn't going to fix people writing non-portable code. A unix coder isn't necessarily going to close the file before reading it. However, it would at least

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Nick Coghlan ncogh...@gmail.com added the comment: I agree we need to add something here to better support the idiom where the close and delete operations on a NamedTemporaryFile are decoupled without the delete becoming a completely independent call to os.unlink(). I agree with RDM's

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Nick Coghlan ncogh...@gmail.com added the comment: Although, for the stdlib version, I wouldn't suppress the OS Error (I'd follow what we currently do for TemporaryDirectory) -- ___ Python tracker rep...@bugs.python.org