Michael Hoffman wrote: > Mike Meyer wrote: >> Guido has made a pronouncement on open vs. file. I think he prefers >> open for opening files, and file for type testing, but may well be >> wrong. I don't think it's critical. > > He has said that open() may be used for things other than files in the > future. So if you want to be sure you're opening a file, use file().
Probably this is the same sort of things as "if you want to be sure your function is working with an integer, you have to test whether it is an integer" (or use a statically typed language). Which is advice that is generally rebutted around here with comments about "duck typing" (as in, if it acts like an integer, then stop worrying about what it actually is). If open() can ever return things other than files, it seems likely it will do so only under conditions that make it pretty much safe to assume that existing code will continue to operate "as expected" (note: not "always with a file"). I'm not going to try to picture just how this might happen, but I could imagine, for example, some kind of support for protocol prefixes (ala "http:" or "ftp:"), or perhaps some sort of support for encrypted or compressed data. Or maybe it would require a prior call to some function to enable the magic that lets open() return non-files. If any of that is reasonable, then using open() is actually the better approach to ensuring your code "does the right thing" in the future, and "file" should still be used in the rare case where you actually want to test whether something is a particular type of thing. -Peter -- http://mail.python.org/mailman/listinfo/python-list
