[Python-Dev] Rationale for NamedTemporaryFile revisited [SEC=UNCLASSIFIED]

[Ole.Nielsen at ga.gov.au]

Thank you very much for the quick reply.

I believe we have to close the file in order be able to read it in - in this
case to feed a unittest. I actually tried to read it in before closing it,
but (as I suspected) the data wasn't available.
 
We use unit testing for pretty much all functions and classes in our system.
Some functions read files and do something with them. We therefore need a
standardised and robust way to generate temporary files that exist on the
filesystem long enough for the function being tested to read them.

We are happy to write a wrapper ourselves that will do just that - but before
doing so we had a look at the standard functionality. Hence the question
about NamedTemporaryFile: What is the purpose of creating a name if it
disappears after the file object is closed? I agree with Dustin that it would
make sense for the file to live on the disk for as long as the File object is
available to the script, closed or not. But I don't think that is the way
NamedTemporaryFile currently works as illustrated in the test script in my
first posting.

Any help or comments, please?

Cheers
Ole Nielsen, Geoscience Australia


-----Original Message-----
From: gvanrossum at gmail.com [mailto:gvanrossum at gmail.com] On Behalf Of Guido
van Rossum
Sent: Friday, 18 January 2008 3:45
To: Nielsen Ole
Cc: python-dev at python.org
Subject: Re: [Python-Dev] Rationale for NamedTemporaryFile revisited
[SEC=UNCLASSIFIED]

Don't close it until you're done with it. Isn't that obvious?

On Jan 17, 2008 8:30 PM,  <Ole.Nielsen at ga.gov.au> wrote:
> I found this posting, and those following it, as I too am baffled that
> NamedTemporaryFile doesn't let you read the generated file - even within
the
> same script.
> For unit testing it is very commonplace to generate a test file on the fly
> and then use it as input the function being tested. NamedTemporaryFile
would
> be the perfect candidate for this except that the file seems to disappear
> immediately after it has been closed. This is contrary to Dustin's comment
> which states that the lifetime extends until the object is garbage
collected.
> The following script illustrates this isn't the case:
>
> from tempfile import NamedTemporaryFile
> fid = NamedTemporaryFile(mode='w',
>                          suffix='.tmp',
>                          dir='.')
>
> fid.write('My temp file')
> fid.close()
>
> # Read it (fid hasn't been garbage collected yet)
> print fid.name
>
> # But the file itself has gone
> fid2 = open(fid.name)
> print fid2.readlines()
>
>
> Can someone please help point me to the best way of creating temporary
files
> in Python that can be read in immediately after their creation.
>
> Thanks
> Ole Nielsen, Geoscience Australia
>
>
>
> On Sun, Mar 18, 2007 at 11:49:55AM +1200, Greg Ewing wrote:
> > I've just discovered the hard way that NamedTemporaryFile
> > automatically deletes the file when you close it. That
> > doesn't seem very useful to me, since surely the reason
> > you're using NamedTemporaryFile instead of TemporaryFile
> > is that you want to do something else with it afterwards?
> > What's the rationale for this behaviour?
>
> For both TemporaryFile and NamedTemporaryFile, the rationale is that
> "temporary" extends until the object is garbage collected.
> TemporaryFile is deleted immediately (to prevent other applications from
> modifying your temporary file).  NamedTemporaryFile is inteded for use
> when you need access to the file by filename during the lifetime of the
> file.  In either case, when the object goes, the file should too.
>
> Dustin
>
>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)