[Python-Dev] Catching "return" and "return expr" at compile time

[M.-A. Lemburg]

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/