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/
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