[Python-Dev] file() vs open(), round 7 (original) (raw)

Donovan Baarda abo at minkirri.apana.org.au
Thu Dec 29 13:29:00 CET 2005

On Sun, 2005-12-25 at 20:38 -0800, Aahz wrote:

Guido sez in http://mail.python.org/pipermail/python-dev/2004-July/045921.html that it is not correct to recommend using file() instead of open(). However, because open() currently is an alias to file(), we end up with the following problem (verified in current HEAD) where doing help(open) brings up the docs for file(): [...] This is confusing. I suggest that we make open() a factory function right now. (I'll submit a bug report (and possibly a patch) after I get agreement.)

Not totally related but...

way back in 2001-2002, I did some work on writing a Virtual File System interface for Python. See;

http://minkirri.apana.org.au/~abo/projects/osVFS

The idea was that you could import a module "vfs" as "os", and then any file operations would go through the virtual file system. I had modules for things "fakeroot", "mountable", "ftpfs" etc. The vfs module had full os functionality so it was a "drop in replacement".

The one wart was open(), because it is the only filesystem operation that wasn't in the os module. At the time I worked around this by adding a vfs.file() method, and suggesting that people alias open() to vfs.file(). Note that os.open() already exists as a low-level file open function, and hence could not be used as a file-object-factory method.

I'm wondering if it wouldn't be a good idea to centralise all filesystem operations into the os module, including open() or file(). Perhaps the builtin open() and file() could call os.file()... or P3K could remove the builtins... I dunno... it just felt ugly at the time that open() was the one oddity.

-- Donovan Baarda <abo at minkirri.apana.org.au> http://minkirri.apana.org.au/~abo/

More information about the Python-Dev mailing list