On Fri, 10 May 2013 05:03:10 +0000, Steven D'Aprano wrote: >>>> There is no sensible use-case for creating a file OBJECT unless it >>>> initially wraps an open file pointer.
> So far the only counter-examples given aren't counter-examples ... Well, sure, if you discount operations like "create this file" and queries like "could I delete this file if I wanted to?" [0] as methods of the file system rather than of a hypothetical file object. What about a distributed system? Suppose I want to create a file object in one place, and send that object to the another place for the file to be read from or written to [1]? Suppose that for security reasons, I have to do it that way, because the first place can only create the objects, and the second place can only access the underly file contents through an existing object? I suppose that this case exists even in a non-distributed system that allows whatever execution unit exists to change its own security settings (POSIX has setuid and setgid functions), or exposes file ACLs as methods of file objects rather than of the OS or file system. What, exactly, does a "file object" represent? And going back to your original comment (which was actually in response to one of my posts), at least some operations on python file objects *could* succeed without having to open the file. An OS could provide truncate, or writeable, on un-opened files; and certainly Python could provide encoding, or isatty, on un-opened files. Of these, truncate might be the closest use case of creating a file object without any intent to write to it, for some definition of "write to it." Dan [0] Yes, I understand that asking first instead of trying to delete the file is just asking to lose any number of potential race conditions, assuming that your system even supports race conditions. [1] Think about a multi-threaded (or otherwise distributed) FTP or HTTP server. No, don't think about the server vs. the client, but rather a "core" server overseeing "sub" servers for different sessions. -- http://mail.python.org/mailman/listinfo/python-list
