[Python-Dev] file() or open()? (original) (raw)

Guido van Rossum guido at python.org
Thu Jul 8 06:43:12 CEST 2004

[SNIP] > In the future, I could see > open() become a factory function again that could return an instance > of a different class depending on the mode argument, the default > encoding for files, or who knows what; but file will always remain a > class.

How is this case different from the whole unicode.encode thread and the worry of having different types of objects returned based on the argument? I would assume that any objects returned would follow the file interface roughly.

Of course, but they don't have to be instances of file to comply with that interface, and that's the whole point. While it's technically possible, using a loophole in new, to let file() return an x for which isinstance(x, file) is false, that's generally ugly (even though there are cases where it's useful). But having a factory function that returns something that complies with a given interface is a standard pattern. Thus, the main use I see for having 'file' around is so that you can say isinstance(x, file) in certain cases where you are interested in distinguishing between real files and objects that merely implement the file interface; while open() is the factory function.

If you look at nondist/sandbox/sio/, you'll find an incomplete experiment with a new standard I/O library implementation, where features like buffering, encoding, line ending translation, and perhaps others (e.g. read/write/update/append), are implemented by stacking various objects. I think Java has a similar design somewhere, even though I've heard that they are replacing that with something called native I/O (or new I/O?) which is apparently faster.

Anyway, here's my future-proof distinction: use open() as the factory function, and file for type-testing.

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list