[issue16122] Allow *open* to accept file-like objects

Changes by Benjamin Peterson : -- resolution: -> rejected ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue16122] Allow *open* to accept file-like objects

Changes by Christian Heimes : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue16122] Allow *open* to accept file-like objects

Christian Heimes added the comment: 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 3

[issue16122] Allow *open* to accept file-like objects

Benjamin Peterson added the comment: 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

[issue16122] Allow *open* to accept file-like objects

New submission from samwyse: 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