[Python-Dev] Placement of os.fdopen functionality
Oren Tirosh
oren-py-d@hishome.net
Mon, 7 Apr 2003 02:16:30 -0400
On Sat, Apr 05, 2003 at 02:35:31PM -0500, Jp Calderone wrote:
> It occurred to me this afternoon (after answering aquestion about creating
> file objects from file descriptors) that perhaps os.fdopen would be more
> logically placed someplace else - of course it could also remain as
> os.fdopen() for whatever deprecation period is warrented.
>
> Perhaps as a class method of the file type, file.fromfd()?
I don't see much point in moving it around just because the place
doesn't seem right but the fact that it's a function rather than a
method means that some things cannot be done in pure Python.
I can create an uninitialized instance of a subclass of 'file' using
file.__new__(filesubclass) but the only way to open it is by name using
file.__init__(filesubclassinstance, 'filename'). A file subclass cannot
be opened from a file descriptor because fdopen always returns a new
instance of 'file'.
If there was some way to open an uninitialized file object from a file
descriptor it would be possible, for example, to write a version of popen
that returns a subclass of file. It could add a method for retrieving
the exit code of the process, do something interesting on __del__, etc.
Here are some alternatives of where this could be implemented, followed
by what a Python implementation of os.fdopen would look like:
1. New form of file.__new__ with more arguments:
def fdopen(fd, mode='r', buffering=-1):
return file.__new__('(fdopen)', mode, buffering, fd)
2. Optional argument to file.__init__:
def fdopen(fd, mode='r', buffering=-1):
return file('(fdopen)', mode, buffering, fd)
3. Instance method (NOT a class method):
def fdopen(fd, mode='r', buffering=-1):
f = file.__new__()
f.fdopen(fd, mode, buffering, '(fdopen)')
return f
Oren