[Python-Dev] Catching "return" and "return expr" at compile time
Wed, 08 Sep 1999 17:08:02 +0200
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":
> The -w switch produces some lovely diagnostics.
> Did we mention that you should definitely consider using the
> -w switch?
> 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
> 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
Y2000: 123 days left
Python Pages: http://www.lemburg.com/python/