On Tue, Aug 16, 2011 at 6:43 PM, Ethan Furman <et...@stoneleaf.us> wrote: > Seebs wrote: >> >> On 2011-08-16, Ethan Furman <et...@stoneleaf.us> wrote: >>> >>> I think warnings should be reserved for language changes and such (like >>> DeprecationWarning, RuntimeWarning, and FutureWarning), not for possible >>> programmer mistakes. >> >> I disagree, on the basis of the following: >> >> The quality of C code I have to deal with has increased dramatically as >> gcc's aggressive use of warnings has spread. > > With gcc you pay the cost once, with Python you would pay it with every run. > A linter would be more along the lines of 'pay it once'.
Agreed; in addition, it's spam. Spam at compile time isn't much of an issue; you type ./configure and make, and a billion messages scroll past you. Spam at run time? Everyone who USES the program has to deal with it, and in amongst the program's own output. I don't know how to have Python emit warnings that wouldn't cause these issues. The only thing I can think of is to have the interactive interpreter default to showing more warnings, which is far from perfect itself. As to 'file' specifically, my 3.2 doesn't seem to have it as a builtin. The return value from open() is _io.TextIOWrapper, so the whole issue of file=open(...) may have been completely dodged. ChrisA -- http://mail.python.org/mailman/listinfo/python-list