Re: [Python-Dev] Rationale for NamedTemporaryFile revisited [SEC=UNCLASSIFIED]
On 18 Jan 2008, 06:42:26, Steve Holden wrote:
[EMAIL PROTECTED] wrote:
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.
The mistake you made was to change the mode from the default w+b. The
following code works on both Windows and Linux:
from tempfile import NamedTemporaryFile
fid = NamedTemporaryFile(mode='w+b',
suffix='.tmp',
dir='.')
fid.write('My temp file')
fid.seek(0)
data = fid.read()
print data
fid.close()
If you need to read the data by opening the file again (from unittest
code for example), then you need to call fid.flush() (no need for seeking).
Again, comp.lang.python, but I could not resist.
regards.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Rationale for NamedTemporaryFile revisited [SEC=UNCLASSIFIED]
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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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, [EMAIL PROTECTED] 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@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/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile revisited [SEC=UNCLASSIFIED]
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guido
van Rossum
Sent: Friday, 18 January 2008 3:45
To: Nielsen Ole
Cc: python-dev@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, [EMAIL PROTECTED] 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@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/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile revisited [SEC=UNCLASSIFIED]
[EMAIL PROTECTED] wrote:
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.
Did you try seeking back to the beginning before attempting your read?
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.
Well you can hardly believe this requirement is so novel that its
absence hasn't been missed in Python, then.
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?
The mistake you made was to change the mode from the default w+b. The
following code works on both Windows and Linux:
from tempfile import NamedTemporaryFile
fid = NamedTemporaryFile(mode='w+b',
suffix='.tmp',
dir='.')
fid.write('My temp file')
fid.seek(0)
data = fid.read()
print data
fid.close()
By the way, this is the sort of topic normally reserved for
comp.lang.python, whose denizens would have straightened you out in no
time flat.
regards
Steve
Cheers
Ole Nielsen, Geoscience Australia
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guido
van Rossum
Sent: Friday, 18 January 2008 3:45
To: Nielsen Ole
Cc: python-dev@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, [EMAIL PROTECTED] 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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Greg Ewing wrote: Gregory P. Smith wrote: I prefer the default of clean up after itself as is to avoid leaving temporary file turds on systems caused by us lazy programmers. Maybe instead of an option there should be a separate function with a different name, such as NewUniqueFile. For the use cases I have in mind, the file isn't really temporary at all. Or rather, only the name is temporary, as it ultimately gets renamed. I'm in favor of adding such a function. I've already wrote my way around this missing feature before. The tempfile modules AFAIK is the only portable way to make a unique filename and open it without exposing a race condition. As it is, it's not that difficult to write this function yourselves using mkstemp directly, but I believe there is a great benefit to have it in the stdlib. -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Scott Dial wrote: Greg Ewing wrote: Maybe instead of an option there should be a separate function with a different name, such as NewUniqueFile. I'm in favor of adding such a function. A tangential question -- why are TemporaryFile and NamedTemporaryFile named in TitleCase, when they're functions and not classes? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Greg Ewing wrote: A tangential question -- why are TemporaryFile and NamedTemporaryFile named in TitleCase, when they're functions and not classes? I wondered the same. At first draft of my email I wrote class operating under the assumption that only classes got to be camel-cased. If I had to guess, the rationale was that they are simply wrappers a class. Nevertheless, tempfile dates well back before the PEP 8 style guidelines. I think consistency would dictate that a newly added function should match the other ones, but I have no strong feelings about this. -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
On 3/21/07, Scott Dial [EMAIL PROTECTED] wrote: Greg Ewing wrote: A tangential question -- why are TemporaryFile and NamedTemporaryFile named in TitleCase, when they're functions and not classes? I wondered the same. At first draft of my email I wrote class operating under the assumption that only classes got to be camel-cased. If I had to guess, the rationale was that they are simply wrappers a class. Nevertheless, tempfile dates well back before the PEP 8 style guidelines. I think consistency would dictate that a newly added function should match the other ones, but I have no strong feelings about this. I wouldn't bet on that. The ElementTree XML module was added to Python 2.5 and it does not follow PEP 8 style (method names are not words separated by underscores). -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Greg Ewing schrieb: Scott Dial wrote: Greg Ewing wrote: Maybe instead of an option there should be a separate function with a different name, such as NewUniqueFile. I'm in favor of adding such a function. A tangential question -- why are TemporaryFile and NamedTemporaryFile named in TitleCase, when they're functions and not classes? Probably because they are factory functions potentially returning a _TemporaryFileWrapper. If they were functions, they'd have to be verbed, e.g. make_temporary_file(). The class/function distinction is not so clear in Python from the user's point of view since there is no different calling syntax. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Georg Brandl wrote: Greg Ewing schrieb: Scott Dial wrote: A tangential question -- why are TemporaryFile and NamedTemporaryFile named in TitleCase, when they're functions and not classes? Probably because they are factory functions potentially returning a _TemporaryFileWrapper. If they were functions, they'd have to be verbed, e.g. make_temporary_file(). The class/function distinction is not so clear in Python from the user's point of view since there is no different calling syntax. Actually the distinction is very clear: class _PrivateClass(object): ... pass ... def FunctionNamedToLookLikeClass(): ... return _PrivateClass() ... pc = _PrivateClass() isinstance(pc, _PrivateClass) True fntllc = FunctionNamedToLookLikeClass() isinstance(fntllc, FunctionNamedToLookLikeClass) Traceback (most recent call last): File stdin, line 1, in module TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types That's sure to be an unpleasant surprise for someone. -- Aaron Bingham Senior Software Engineer [EMAIL PROTECTED] Tel. +49 (0)351 4173-146 Fax +49 (0)351 4173-109 Cenix BioScience GmbH Tatzberg 47 01307 Dresden, Germany www.cenix-bioscience.com - Sitz der Gesellschaft (Place of Business): Dresden Geschäftsführer (CEO): Dr. Christophe J. Echeverri Amtsgericht (Local Court): Dresden, HRB 19964 Ust-ID (VAT-No.): DE205824437 - ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Aaron Bingham schrieb: Georg Brandl wrote: Greg Ewing schrieb: Scott Dial wrote: A tangential question -- why are TemporaryFile and NamedTemporaryFile named in TitleCase, when they're functions and not classes? Probably because they are factory functions potentially returning a _TemporaryFileWrapper. If they were functions, they'd have to be verbed, e.g. make_temporary_file(). The class/function distinction is not so clear in Python from the user's point of view since there is no different calling syntax. Actually the distinction is very clear: class _PrivateClass(object): ... pass ... def FunctionNamedToLookLikeClass(): ... return _PrivateClass() ... pc = _PrivateClass() isinstance(pc, _PrivateClass) True fntllc = FunctionNamedToLookLikeClass() isinstance(fntllc, FunctionNamedToLookLikeClass) Traceback (most recent call last): File stdin, line 1, in module TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types That's sure to be an unpleasant surprise for someone. whisperduck typing.../whisper But you have a valid point. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Georg Brandl wrote: Aaron Bingham schrieb: Georg Brandl wrote: Greg Ewing schrieb: Scott Dial wrote: A tangential question -- why are TemporaryFile and NamedTemporaryFile named in TitleCase, when they're functions and not classes? Probably because they are factory functions potentially returning a _TemporaryFileWrapper. If they were functions, they'd have to be verbed, e.g. make_temporary_file(). The class/function distinction is not so clear in Python from the user's point of view since there is no different calling syntax. Actually the distinction is very clear: class _PrivateClass(object): ... pass ... def FunctionNamedToLookLikeClass(): ... return _PrivateClass() ... pc = _PrivateClass() isinstance(pc, _PrivateClass) True fntllc = FunctionNamedToLookLikeClass() isinstance(fntllc, FunctionNamedToLookLikeClass) Traceback (most recent call last): File stdin, line 1, in module TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types That's sure to be an unpleasant surprise for someone. whisperduck typing.../whisper But you have a valid point. Sure, isinstance was only meant as an example. Anything that expects FunctionNamedToLookLikeClass to exhibit class-like behaviors beyond a call returning a new instance will fail. -- Aaron Bingham Senior Software Engineer [EMAIL PROTECTED] Tel. +49 (0)351 4173-146 Fax +49 (0)351 4173-109 Cenix BioScience GmbH Tatzberg 47 01307 Dresden, Germany www.cenix-bioscience.com - Sitz der Gesellschaft (Place of Business): Dresden Geschäftsführer (CEO): Dr. Christophe J. Echeverri Amtsgericht (Local Court): Dresden, HRB 19964 Ust-ID (VAT-No.): DE205824437 - ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Georg Brandl wrote: The class/function distinction is not so clear in Python from the user's point of view since there is no different calling syntax. There *is* a visible distinction, though -- you can subclass classes but not functions. If these are uppercased because they wrap classes, why not just expose the class directly? Or if that's an implementation detail, it shouldn't affect the casing of the name. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Greg Ewing wrote: A tangential question -- why are TemporaryFile and NamedTemporaryFile named in TitleCase, when they're functions and not classes? I wondered the same. At first draft of my email I wrote class operating under the assumption that only classes got to be camel-cased. If I had to guess, the rationale was that they are simply wrappers a class. Nevertheless, tempfile dates well back before the PEP 8 style guidelines. I think consistency would dictate that a newly added function should match the other ones, but I have no strong feelings about this. -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
On Mon, Mar 19, 2007 at 12:20:59PM +1200, Greg Ewing wrote: Damien Miller wrote: That annoyed me too, so I submitted a patch[1] that was recently committed. That looks good. Seems to me it should really be the default behaviour, but I suppose that would break code that was relying on the automatic deletion. I prefer the default of clean up after itself as is to avoid leaving temporary file turds on systems caused by us lazy programmers. -greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Gregory P. Smith wrote: I prefer the default of clean up after itself as is to avoid leaving temporary file turds on systems caused by us lazy programmers. Maybe instead of an option there should be a separate function with a different name, such as NewUniqueFile. For the use cases I have in mind, the file isn't really temporary at all. Or rather, only the name is temporary, as it ultimately gets renamed. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Greg Ewing schrieb: 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? It now (2.6) has a keyword argument for not closing the file. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Damien Miller wrote: That annoyed me too, so I submitted a patch[1] that was recently committed. That looks good. Seems to me it should really be the default behaviour, but I suppose that would break code that was relying on the automatic deletion. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Rationale for NamedTemporaryFile?
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? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
