[Python-Dev] Placement of os.fdopen functionality

[Oren Tirosh]

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