> That was probably a checkin I made. I would have left it alone except the > code was > > file = open(...) > > As long as I was changing the variable name to not mask the builtin I > changed the call as well. Had it been > > f = open(...) > > I probably would have kept my hands off. Hm... I'm not particularly concerned over fixing all code that uses file as a local variable name, unless it actually is likely to need to reference the file class by name; builtins are in the last scope searched for the very reason that no programmer is expected to keep up with all additions to the built-in library, so locals hiding built-ins is okay. (Not that it isn't a good idea to avoid obvious clashes -- 'str' for string variables and 'type' for type variables being the most obvious stumbling blocks.) > In any case, I was under the impression that file() was the wave of the > future and open() a nod to the past. Now you know better... --Guido van Rossum (home page: http://www.python.org/~guido/)
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