Greg Ward wrote:
On 07 September 1999, Tim Peters said:
The latter, if for no other reason than that new users should get bludgeoned into good practice from their first day. If something's serious enough to trigger a warning, and you insist on doing it anyway, then you should at least know enough about Python to be able to find the -W switch <wink>.
Note that in response to 1,379 distinct complaints about insane Perl semantics, TomC's stock answer is that every serious Perl programmer runs with -w and "use strict". He's right! Every serious Perl programmer does. Perl picked the wrong default, letting naive programmers hang themselves 1,379 distinct ways by default.
I agree, but I'm only willing to do so publicly because Tim has. So does the Perl documentation (ie. Tom C., I assume); from "man perl":
DIAGNOSTICS The -w switch produces some lovely diagnostics. [...] Did we mention that you should definitely consider using the -w switch?
BUGS The -w switch is not mandatory.
D'you think that's a hint?
Obviously, there *must* be a way to turn off warnings, so we can continue to run our crufty, bug-ridden old code without too many problems.
Greg S.'s suggestion for being able to customize *which* warnings are printed is also important. Much hair was pulled when Perl 5.004 was released with a whole bunch of new warning messages -- lots of people had to go back and "fix" working code, or remove the -w switch from production scripts to clean up the mess on their stderr, etc. I suspect most of those people (myself included) were enlightened by the new warnings, but annoyed by having to go and fix what wasn't necessarily broken. A lot of people now recommend using -w only when developing, and removing it for production use, simply because of the risk of new warning messages when you upgrade Perl.
I'd suggest to use the -W <opt>[=<value>] kind of command line option interface for warnings and to also add an environment variable to customize the standard settings, e.g. PYTHONWARNINGS. About enabling warning per default: you should consider the fact that much code out there will probably produce such warnings, even if it is perfectly valid (e.g. consider Skip's example with while 1:...). Enabling it is definitely not a good idea for production code -- it is during the development step. Since production code is likely to run using -O, I suggest disabling warnings when -O is used and enabling them otherwise. Also, I'd like to second GregS' idea with the sys.warnings dict. Together with a generic -W <opt>=<value> interface this would be great for adding customized warnings to Python scripts (i.e. not only the ones that the interpreter itself produces). -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 123 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/