Mailing List Archive: Python: Bugs

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Index | Next | Previous | View Threaded

report at bugs

Jun 30, 2012, 4:01 PM

Post #1 of 8 (145 views)
Permalink

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows

Daniel Lenski <dlenski [at] gmail> 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 occurs in the __exit__() method.

On Sat, Jun 30, 2012 at 1:46 AM, Davide Rizzo <report [at] bugs>wrote:

>
> Davide Rizzo <sorcio [at] gmail> added the comment:
>
> Daniel, Nick, shouldn't the context manager yield f within a with block?
>
> ----------
> nosy: +davide.rizzo
>
> _______________________________________
> Python tracker <report [at] bugs>
> <http://bugs.python.org/issue14243>
> _______________________________________
>

----------
title: tempfile.NamedTemporaryFile not particularly useful on Windows -> tempfile.NamedTemporaryFile not particularly useful on Windows

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14243>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Jul 1, 2012, 10:19 AM

Post #2 of 8 (131 views)
Permalink

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows [In reply to]

Daniel Lenski <dlenski [at] gmail> 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 manager
exits or when the object is garbage collected? Would it then get unlinked?

My preference would be to specify the behavior of close/__exit__/GC
operations at the time of the NamedTemporaryFile creation, so that the rest
of the code can be left unchanged.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14243>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Jul 1, 2012, 1:30 PM

Post #3 of 8 (135 views)
Permalink

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows [In reply to]

Richard Oudkerk <shibturn [at] gmail> 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 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.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14243>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Jul 1, 2012, 1:37 PM

Post #4 of 8 (138 views)
Permalink

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows [In reply to]

Antoine Pitrou <pitrou [at] free> 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.

Sounds like a good way forward.

----------
components: +Windows
stage: -> needs patch
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14243>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Jul 1, 2012, 1:39 PM

Post #5 of 8 (134 views)
Permalink

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows [In reply to]

Tim Golden <mail [at] timgolden> added the comment:

On 01/07/2012 21:37, Antoine Pitrou wrote:
>
> Antoine Pitrou <pitrou [at] free> 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.
>
> Sounds like a good way forward.

Agreed. Richard: do you have time to put something together?
I'm happy to try if you don't.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14243>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Jul 1, 2012, 3:46 PM

Post #6 of 8 (138 views)
Permalink

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows [In reply to]

Richard Oudkerk <shibturn [at] gmail> 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 opened with SH_DENYNO and O_TEMPORARY, then you must reopen it using SH_DENYNO and O_TEMPORARY.

However, I have an initial implementation of os.sopen() which makes the following work:

import os, tempfile

FNAME = "foo.txt"
DATA = "hello bob"

def opener(name, flag, mode=0o777):
return os.sopen(name, flag | os.O_TEMPORARY, os.SH_DENYNO, mode)

with open(FNAME, "w", opener=opener) as f:
f.write(DATA)
f.flush()
with open(FNAME, "r", opener=opener) as f:
assert f.read() == DATA

assert not os.path.exists(FNAME)

BTW, Maybe it would be better to add a keyword-only shareflag argument to os.open() rather than add os.sopen().

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14243>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Jul 1, 2012, 4:45 PM

Post #7 of 8 (137 views)
Permalink

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows [In reply to]

Richard Oudkerk <shibturn [at] gmail> 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 trying to reopen a NamedTemporaryFile fails on Windows is because when we reopen we need to use O_TEMPORARY.

The following works for unmodified python:

import os, tempfile

DATA = b"hello bob"

def temp_opener(name, flag, mode=0o777):
return os.open(name, flag | os.O_TEMPORARY, mode)

with tempfile.NamedTemporaryFile() as f:
f.write(DATA)
f.flush()
with open(f.name, "rb", opener=temp_opener) as f:
assert f.read() == DATA

assert not os.path.exists(f.name)

So maybe we should just define tempfile.opener().

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14243>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

report at bugs

Jul 1, 2012, 5:45 PM

Post #8 of 8 (135 views)
Permalink

[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows [In reply to]

Nick Coghlan <ncoghlan [at] gmail> 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 "reopen" StringIO and BytesIO objects).

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14243>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads