I'm once again frustrated by a third-party module that only accepts filenames, not already-opened file-like objects.  This prevents me from passing in StringIO objects or any of the standard file streams.  Currently, *open()* function accepts strings or (in Python 3.X) integers.  I propose that *open()* accept "file-like" objects, either returning them unchanged, or by returning a wrapper object.  While there are many different types of file-like objects, they all have one characteristic in common: the presence of a .close() method.

A non-wrapped version of open() could be as simple as this:

  try:
    file = original_open(name, mode, buffering)
  except TypeError:
    if hasattr(name, 'close'):
        return name
    raise

Returning a wrapper object would be slightly more complicated, but would allow the wrapped object to remain open even after the wrapper is closed.

So, this is supposed to be a kludge for 3rd-party libraries that don't support using file objects? Immediately calling open() isn't necessarily what such a library will do. It could process the path somehow. Anyway, it's not clear what the semantics of the wrapper open() would return would be.

I'm going to close this. If you want to push it, you can bring it up on the python-ideas mailing list.

I've another argument against your proposal:

open() always wraps a operating system resource and not some Python object. At the lowest level open() interacts with a file descriptor (aka file handler on Windows). I don't like to break the promise.

Lot's of 3rd party extensions don't support file-like objects because they wrap C libraries that either need a path, a file descriptor or a FILE* pointer.