[Guido van Rossum] > Oops, yes. I didn't write that, and it doesn't convey my feelings > about file() vs. open(). Here's a suggestion for better words: > > "The file class is new in Python 2.2. It represents the type (class) > of objects returned by the built-in open() function. Its constructor > is an alias for open(), but for future and backwards compatibility, > open() remains preferred." This is slightly saddening. I perceived the introduction of `file()' as a nice cleanup in Python. I wonder if the quote above states the real reason. Sometimes, we produce rationalisations for what was more of an emotion initially. Here, another message on the same topic says: > Maybe you'll change your mind when open() can return other objects > besides files. Granted that `open()' may be preferred for backwards compatibility, but if it is meant to change or improve in the long run, maybe it should be avoided, precisely for future compatibility. Currently, I use `file()' when the meaning of my code is to create a file object to be operated upon, but to otherwise let Python manage it. Yet, I still use `open()' when the meaning of my code is opening a file, usually implying that I will also explicitly close it. If `open()' could return objects of various types, and my goal is really to get a file object, may I presume that `file()' imposes itself as preferred? -- François Pinard http://www.iro.umontreal.ca/~pinard
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4