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 <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
