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