[Python-Dev] Placement of os.fdopen functionality (original) (raw)

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