object.enable() anti-pattern

[Dan Sommers]

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.