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

[Guido van Rossum]

> [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/)