Re: [Python-Dev] Warn about mktemp once again?
Greg Ewing wrote:
[EMAIL PROTECTED] wrote:
I'm not disagreeing with you, but it seems odd that os.fdopen doesn't
simply
obey the mode of the file descriptor it receives as its argument
I'm not even sure if it's possible to find out the mode
that a file descriptor was opened with -- is it?
int mode = fcntl(fd, F_GETFL);
switch(mode) {
case O_RDONLY: ...
case O_WRONLY: ...
case O_RDWR: ...
}
Certainly there's no way to tell whether you want it
treated as binary, so at least that much of the mode
needs to be specified.
Agreed.
-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] Warn about mktemp once again?
Same here. In fact, is there a good reason to have mkstemp() return the fd (except backward compatibility)? Except for backwards compatibility: is there a good reason to keep os.mkstemp at all? The tradition is that all APIs in os expose the system calls as-is, i.e. they don't try to adjust the result values at all. This has the advantage that the caller can use their system's man page to find out all details, and trust that the Python wrapper does exactly the same. For mkstemp, there are two special issues: the C API modifies the string parameter, which cannot be exposed to Python as-is (hence the two result values), and it isn't a system call (at least not on POSIX), so it doesn't really need to be exposed, except perhaps to also provide this on non-POSIX systems where a regular POSIX implementation (in Python) would fail. Regards, Martin ___ 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] Warn about mktemp once again?
2008/4/29 Martin v. Löwis [EMAIL PROTECTED]: Same here. In fact, is there a good reason to have mkstemp() return the fd (except backward compatibility)? Except for backwards compatibility: is there a good reason to keep os.mkstemp at all? Greg Ewing's use-case is one I've also had at times - ie. as a convenience function for creating a somewhat temporary file that is randomly named, but persists beyond the closing of the file. If the function doesn't stay in os it doesn't make any difference to me though :-) ___ 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] Warn about mktemp once again?
Greg I'd like to see a variation of mkstemp() that returns a file Greg object instead of a file descriptor... http://bugs.python.org/issue2717 Comments welcome. Skip ___ 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] Warn about mktemp once again?
Greg Ewing wrote: Guido van Rossum wrote: IMO mkstemp() is a major pain because you have to use raw file descriptors on the return value. I'd much rather recommend [Named]TemporaryFile which return streams. The problem with NamedTemporaryFile is that it deletes the file as soon as you close it, which makes the named-ness of it rather useless, as far as I can see. If you don't want that to happen, you have to use mkstemp. That much has been fixed in 2.6 - you can now just pass delete=False to the NamedTemporaryFile constructor to stop it doing that. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Warn about mktemp once again?
David Harrison wrote: 2008/4/29 Martin v. Löwis [EMAIL PROTECTED]: Same here. In fact, is there a good reason to have mkstemp() return the fd (except backward compatibility)? Except for backwards compatibility: is there a good reason to keep os.mkstemp at all? Greg Ewing's use-case is one I've also had at times - ie. as a convenience function for creating a somewhat temporary file that is randomly named, but persists beyond the closing of the file. If the function doesn't stay in os it doesn't make any difference to me though :-) As of 2.6, Greg's use case is addressed by the new 'delete' parameter on tempfile.NamedTemporaryFile. The implementation of the tempfile module uses os.mkstemp() though, so getting rid of the latter might cause a few problems :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Warn about mktemp once again?
On 4/29/2008 2:18 PM, Nick Coghlan wrote: Same here. In fact, is there a good reason to have mkstemp() return the fd (except backward compatibility)? Except for backwards compatibility: is there a good reason to keep os.mkstemp at all? Greg Ewing's use-case is one I've also had at times - ie. as a convenience function for creating a somewhat temporary file that is randomly named, but persists beyond the closing of the file. If the function doesn't stay in os it doesn't make any difference to me though :-) As of 2.6, Greg's use case is addressed by the new 'delete' parameter on tempfile.NamedTemporaryFile. Then I personally don't have any objection to the removal of os.mkstemp. Since we're at it, a common pattern I use is to create temporary file to atomically replace files: I create a named temporary file in the same directory of the file I want to replace; write data into it; close it; and move it (POSIX move: rename with silent overwrite) to the destination file. AFAIK, this is allows an atomic file replacemente on most filesystems. I believe this is a common useful pattern that could be handled in module tmpfile (especially since the final rename step requires a little care to be truly multiplatform). -- Giovanni Bajo Develer S.r.l. http://www.develer.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
[Python-Dev] socket.try_reuse_address()
Since the recent changes to networking-oriented tests (issue 2550, r62234 and r62237), I think it's safe to say stability of the test suite on all the non-Windows platforms has improved significantly in this area (I don't recall seeing any socket errors in *nix buildbot logs since those commits). However, Windows buildbots are still periodically failing. More specifically, my Windows buildbots are still failing. One thing that's different about my buildbots is that two are being run at the same time for both trunk and py3k -- one doing an x86 build, the other doing x64 build. Since the changes in the aforementioned revisions, the behaviour of my buildbots has definitely improved -- they no longer completely wedge on test_async(chat|core), mainly due to abolishing all use of SO_REUSEADDR as a socket option in any network-oriented tests. However, periodically, they're still dying/failing in a variety of ways -- see relevant log snippets at the end of this e-mail for examples. I attribute this to the fact that SO_REUSEADDR is still set as a socket option in asyncore.py and SocketServer.py. Basically, SO_REUSEADDR should *never* be set on Windows for TCP/IP sockets. Using asyncore.py as an example, here are two ways we could handle this: 1. Hard code the Windows opt-out: --- asyncore.py (revision 62509) +++ asyncore.py (working copy) @@ -267,6 +267,8 @@ def set_reuse_addr(self): # try to re-use a server port if possible +if os.name == 'nt' and self.socket.socket_type != socket.SOCK_DGRAM: +return try: self.socket.setsockopt( socket.SOL_SOCKET, socket.SO_REUSEADDR, 2. Introduce socket.try_reuse_address(): --- asyncore.py (revision 62509) +++ asyncore.py (working copy) @@ -266,15 +266,7 @@ self.add_channel(map) def set_reuse_addr(self): -# try to re-use a server port if possible -try: -self.socket.setsockopt( -socket.SOL_SOCKET, socket.SO_REUSEADDR, -self.socket.getsockopt(socket.SOL_SOCKET, - socket.SO_REUSEADDR) | 1 -) -except socket.error: -pass +self.socket.try_reuse_address() With try_use_address implemented as follows: --- socket.py (revision 62509) +++ socket.py (working copy) @@ -197,6 +197,10 @@ Return a new socket object connected to the same system resource. return _socketobject(_sock=self._sock) +def try_reuse_address(self): +if not (os.name == 'nt' and self._sock.type != SOCK_DGRAM): +self._sock.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1) + def makefile(self, mode='r', bufsize=-1): makefile([mode[, bufsize]]) - file object I prefer the latter as it's cleaner, easier to document and encapsulates what we're trying to do relatively well. The affected modules would be asyncore.py, SocketServer.py and idlelib/rpc.py. Thoughts? Regards, Trent. eg1 test_ftplib remoteFailed: [Failure instance: Traceback (failure with no frames): twisted.internet.error.ConnectionLost: Connection to the other side was lost in a non-clean fashion. ] /eg1 eg2 test_asynchat test test_asynchat failed -- errors occurred; run in verbose mode for details [snip to bottom of log where test_asynchat is re-run] 1 test failed: test_asynchat 33 tests skipped: test__locale test_aepack test_applesingle test_cProfile test_commands test_crypt test_curses test_dbm test_epoll test_fcntl test_fork1 test_gdbm test_grp test_ioctl test_kqueue test_macostools test_mhlib test_nis test_openpty test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd test_resource test_scriptpackages test_signal test_syslog test_threadsignals test_wait3 test_wait4 test_zipfile64 Those skips are all expected on win32. Re-running failed tests in verbose mode Re-running test 'test_asynchat' in verbose mode test_close_when_done (test.test_asynchat.TestAsynchat) ... ok test_empty_line (test.test_asynchat.TestAsynchat) ... ok test_line_terminator1 (test.test_asynchat.TestAsynchat) ... ok test_line_terminator2 (test.test_asynchat.TestAsynchat) ... ok test_line_terminator3 (test.test_asynchat.TestAsynchat) ... ok test_none_terminator (test.test_asynchat.TestAsynchat) ... ok test_numeric_terminator1 (test.test_asynchat.TestAsynchat) ... ok test_numeric_terminator2 (test.test_asynchat.TestAsynchat) ... ok test_simple_producer (test.test_asynchat.TestAsynchat) ... ok test_string_producer (test.test_asynchat.TestAsynchat) ... ok test_close_when_done (test.test_asynchat.TestAsynchat_WithPoll) ... ok test_empty_line (test.test_asynchat.TestAsynchat_WithPoll) ... ok test_line_terminator1 (test.test_asynchat.TestAsynchat_WithPoll) ... ok test_line_terminator2 (test.test_asynchat.TestAsynchat_WithPoll) ... ok test_line_terminator3 (test.test_asynchat.TestAsynchat_WithPoll) ... ok test_none_terminator
Re: [Python-Dev] Warn about mktemp once again?
On Tue, 2008-04-29 at 15:34 +0200, Giovanni Bajo wrote: As of 2.6, Greg's use case is addressed by the new 'delete' parameter on tempfile.NamedTemporaryFile. Then I personally don't have any objection to the removal of os.mkstemp. os.mkstemp is still useful when you *don't* need the file object, but the actual file descriptor, for passing to C code or to the child processes, or to mmap.mmap and such. It is also familiar to the Unix/C hackers, and it should cost very little to keep it around. Since we're at it, a common pattern I use is to create temporary file to atomically replace files: I create a named temporary file in the same directory of the file I want to replace; write data into it; close it; and move it (POSIX move: rename with silent overwrite) to the destination file. AFAIK, this is allows an atomic file replacemente on most filesystems. I believe this is a common useful pattern that could be handled in module tmpfile (especially since the final rename step requires a little care to be truly multiplatform). I agree, having a tempfile class with rename-on-close semantics would be very useful. ___ 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] socket.try_reuse_address()
Maybe it would be better considering Windows CE systems too:
- if os.name == 'nt'
+ if os.name in ('nt', 'ce')
Moreover if the method is called try_reuse_address I'd expect that
self._sock.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1) would be placed
inside a try/except block.
On 29 Apr, 15:58, Trent Nelson [EMAIL PROTECTED] wrote:
Since the recent changes to networking-oriented tests (issue 2550, r62234 and
r62237), I think it's safe to say stability of the test suite on all the
non-Windows platforms has improved significantly in this area (I don't recall
seeing any socket errors in *nix buildbot logs since those commits).
However, Windows buildbots are still periodically failing. More
specifically, my Windows buildbots are still failing. One thing that's
different about my buildbots is that two are being run at the same time for
both trunk and py3k -- one doing an x86 build, the other doing x64 build.
Since the changes in the aforementioned revisions, the behaviour of my
buildbots has definitely improved -- they no longer completely wedge on
test_async(chat|core), mainly due to abolishing all use of SO_REUSEADDR as a
socket option in any network-oriented tests.
However, periodically, they're still dying/failing in a variety of ways --
see relevant log snippets at the end of this e-mail for examples. I
attribute this to the fact that SO_REUSEADDR is still set as a socket option
in asyncore.py and SocketServer.py. Basically, SO_REUSEADDR should *never*
be set on Windows for TCP/IP sockets. Using asyncore.py as an example, here
are two ways we could handle this:
1. Hard code the Windows opt-out:
--- asyncore.py (revision 62509)
+++ asyncore.py (working copy)
@@ -267,6 +267,8 @@
def set_reuse_addr(self):
# try to re-use a server port if possible
+ if os.name == 'nt' and self.socket.socket_type != socket.SOCK_DGRAM:
+ return
try:
self.socket.setsockopt(
socket.SOL_SOCKET, socket.SO_REUSEADDR,
2. Introduce socket.try_reuse_address():
--- asyncore.py (revision 62509)
+++ asyncore.py (working copy)
@@ -266,15 +266,7 @@
self.add_channel(map)
def set_reuse_addr(self):
- # try to re-use a server port if possible
- try:
- self.socket.setsockopt(
- socket.SOL_SOCKET, socket.SO_REUSEADDR,
- self.socket.getsockopt(socket.SOL_SOCKET,
- socket.SO_REUSEADDR) | 1
- )
- except socket.error:
- pass
+ self.socket.try_reuse_address()
With try_use_address implemented as follows:
--- socket.py (revision 62509)
+++ socket.py (working copy)
@@ -197,6 +197,10 @@
Return a new socket object connected to the same system resource.
return _socketobject(_sock=self._sock)
+ def try_reuse_address(self):
+ if not (os.name == 'nt' and self._sock.type != SOCK_DGRAM):
+ self._sock.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)
+
def makefile(self, mode='r', bufsize=-1):
makefile([mode[, bufsize]]) - file object
I prefer the latter as it's cleaner, easier to document and encapsulates what
we're trying to do relatively well. The affected modules would be
asyncore.py, SocketServer.py and idlelib/rpc.py. Thoughts?
Regards,
Trent.
eg1
test_ftplib
remoteFailed: [Failure instance: Traceback (failure with no frames):
twisted.internet.error.ConnectionLost: Connection to the other side was lost
in a non-clean fashion.
]
/eg1
eg2
test_asynchat
test test_asynchat failed -- errors occurred; run in verbose mode for details
[snip to bottom of log where test_asynchat is re-run]
1 test failed:
test_asynchat
33 tests skipped:
test__locale test_aepack test_applesingle test_cProfile
test_commands test_crypt test_curses test_dbm test_epoll
test_fcntl test_fork1 test_gdbm test_grp test_ioctl test_kqueue
test_macostools test_mhlib test_nis test_openpty test_ossaudiodev
test_pipes test_poll test_posix test_pty test_pwd test_resource
test_scriptpackages test_signal test_syslog test_threadsignals
test_wait3 test_wait4 test_zipfile64
Those skips are all expected on win32.
Re-running failed tests in verbose mode
Re-running test 'test_asynchat' in verbose mode
test_close_when_done (test.test_asynchat.TestAsynchat) ... ok
test_empty_line (test.test_asynchat.TestAsynchat) ... ok
test_line_terminator1 (test.test_asynchat.TestAsynchat) ... ok
test_line_terminator2 (test.test_asynchat.TestAsynchat) ... ok
test_line_terminator3 (test.test_asynchat.TestAsynchat) ... ok
test_none_terminator (test.test_asynchat.TestAsynchat) ... ok
test_numeric_terminator1 (test.test_asynchat.TestAsynchat) ... ok
test_numeric_terminator2 (test.test_asynchat.TestAsynchat) ... ok
test_simple_producer (test.test_asynchat.TestAsynchat) ... ok
test_string_producer
Re: [Python-Dev] socket.try_reuse_address()
Giampaolo Rodola' wrote:
Maybe it would be better considering Windows CE systems too:
- if os.name == 'nt'
+ if os.name in ('nt', 'ce')
Cygwin? I don't know how Unix-like it is.
regards
Steve
--
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] socket.try_reuse_address()
Giampaolo Rodola' wrote:
Maybe it would be better considering Windows CE systems too:
- if os.name == 'nt'
+ if os.name in ('nt', 'ce')
Cygwin? I don't know how Unix-like it is.
Yeah, that's a fair point, it's the behaviour of the underlying Winsock API
we're targeting, so it would apply to Cygwin as well. (And CE and anything
else on Windows.)
Trent.
___
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] Warn about mktemp once again?
On Mon, Apr 28, 2008 at 10:49 PM, Greg Ewing [EMAIL PROTECTED] wrote: The problem with NamedTemporaryFile is that it deletes the file as soon as you close it, which makes the named-ness of it rather useless, as far as I can see. Why? You can flush it and then all the data is on the disk. The whole point of [Named]TemporaryFile is to automate the cleanup as well as the creation. -- --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
[Python-Dev] Module Suggestion: ast
Hi all, I would like to propose a new module for the stdlib for Python 2.6 and higher: ast. The motivation for this module is the pending deprecation for compiler.ast which is widely used (debugging, template engines, code coverage etc.). _ast is a very solid module and is without a doubt easier to maintain then compiler.ast which was written in Python, it's lacking some features such as pretty printing the AST or traversing it. The idea of ast would be adding high level functionality for easier working with the AST. It currently provides these features: - pretty printing AST objects - a parse function as easier alias for compile() + flag - operator-node - operator symbol mappings (eg: _ast.Add - '+') - methods to modify lineno / col_offset (incrementing or copying the data over from existing nodes) - getting the fields of nodes as dicts - iterating over all child nodes - a function to get the docstring or an AST node - a node walker that yields all child-nodes recursively - a `NodeVistor` and `NodeTransformer` Additionally there is a `literate_eval` function in that module that can safely evaluate python literals in a string. Module and unittests are located in the Pocoo Sandbox HG repository: http://dev.pocoo.org/hg/sandbox/file/tip/ast/ast.py http://dev.pocoo.org/hg/sandbox/file/tip/ast/test_ast.py A slightly modified version of the ast.py module for Python 2.5 compatibility is currently in use for the Mako template engine to achieve support for Google's AppEngine. An example module for the NodeVisitor is in the repository which converts a Python AST back into Python source code: http://dev.pocoo.org/hg/sandbox/file/tip/ast/codegen.py Regards, Armin ___ 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] Warn about mktemp once again?
Same here. In fact, is there a good reason to have mkstemp() return the fd (except backward compatibility)? Except for backwards compatibility: is there a good reason to keep os.mkstemp at all? Greg Ewing's use-case is one I've also had at times - ie. as a convenience function for creating a somewhat temporary file that is randomly named, but persists beyond the closing of the file. If the function doesn't stay in os it doesn't make any difference to me though :-) I was talking about the specific implementation, which happens to be a wrapper around the C library's mkstemp. For the use case in question, I think passing delete=False to NamedTemporaryFile would work just as well. Regards, Martin ___ 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] Module Suggestion: ast
An example module for the NodeVisitor is in the repository which converts a Python AST back into Python source code: http://dev.pocoo.org/hg/sandbox/file/tip/ast/codegen.py And another example for the same functionality is in Demo/parser/unparse.py. Regards, Martin ___ 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] Module Suggestion: ast
Just a thought, but it would be great if this could be implemented over the top of a C layer that operates on real AST nodes (rather than the PyObject representation of those nodes). I'm working on stuff to perform code optimization at the AST level (see the tlee-ast-optimize branch), and the functionality you're describing may wind up being very useful to me. I've got more to say on the topic, but I'm at work right now. Just something to keep in mind. Cheers, T Armin Ronacher wrote: Hi all, I would like to propose a new module for the stdlib for Python 2.6 and higher: ast. The motivation for this module is the pending deprecation for compiler.ast which is widely used (debugging, template engines, code coverage etc.). _ast is a very solid module and is without a doubt easier to maintain then compiler.ast which was written in Python, it's lacking some features such as pretty printing the AST or traversing it. The idea of ast would be adding high level functionality for easier working with the AST. It currently provides these features: - pretty printing AST objects - a parse function as easier alias for compile() + flag - operator-node - operator symbol mappings (eg: _ast.Add - '+') - methods to modify lineno / col_offset (incrementing or copying the data over from existing nodes) - getting the fields of nodes as dicts - iterating over all child nodes - a function to get the docstring or an AST node - a node walker that yields all child-nodes recursively - a `NodeVistor` and `NodeTransformer` Additionally there is a `literate_eval` function in that module that can safely evaluate python literals in a string. Module and unittests are located in the Pocoo Sandbox HG repository: http://dev.pocoo.org/hg/sandbox/file/tip/ast/ast.py http://dev.pocoo.org/hg/sandbox/file/tip/ast/test_ast.py A slightly modified version of the ast.py module for Python 2.5 compatibility is currently in use for the Mako template engine to achieve support for Google's AppEngine. An example module for the NodeVisitor is in the repository which converts a Python AST back into Python source code: http://dev.pocoo.org/hg/sandbox/file/tip/ast/codegen.py Regards, Armin ___ 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/tom%40vector-seven.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] Warn about mktemp once again?
Guido van Rossum wrote: Why? You can flush it and then all the data is on the disk. That might be all right on Unix, but I would be worried that having the file open could prevent some other things being done with it on some platforms, such as renaming. You might also want to pass the file name on to some other process. The whole point of [Named]TemporaryFile is to automate the cleanup as well as the creation. The docs (at least up to 2.5) don't make it at all clear that this is the *whole* point of *both* these functions. The doc for NamedTemporaryFile seems to disavow any guarantee that you will be able to do anything with the name while the file is open. If you can't use the name while the file is open, and the file ceases to exist when it's closed, then what use is it to have the name? The obvious conclusion is that the point of NamedTemporaryFile is to give you a file that *doesn't* go away when you close it, and has a name so you can go on to do other things with it. So I plead ignorance due to misleading documentation. -- 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
