> [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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4