[Python-Dev] Warning Framework (PEP 230)

[Guido van Rossum]

[me]
> > Disagree.  Warnings are there mostly for the Python system to warn the
> > Python programmer.  The most heavy use will come from the standard
> > library, not from user code.

[Paul Prescod]
> Most Python code is part of some library or another. It may not be the
> standard library but its still a library. Perl and Java both make
> warnings (especially about deprecation) very easy *for user code*.

Hey.  I'm not making it impossible to use warnings.  I'm making it
very easy.  All you have to do is put "from warnings import warn" at
the top of your library module.  Requesting a built-in or even a new
statement is simply excessive.

> > >  * it should be possible to strip warnings as an optimization step. That
> > > may require interpreter and syntax support.
> > 
> > I don't see the point of this.  I think this comes from our different
> > views on who should issue warnings.
> 
> Everyone who creates a reusable library will want to issue warnings.
> That is to say, most serious Python programmers.
> 
> Anyhow, let's presume that it is only the standard library that issues
> warnings (for arguments sake). What if I have a speed-critical module
> that triggers warnings in an inner loop. Turning off the warning doesn't
> turn off the overhead of the warning infrastructure. I should be able to
> turn off the overhead easily -- ideally from the Python command line.
> And I still feel that part of that "overhead" is in the code that tests
> to determine whether to issue the warnings. There should be a way to
> turn off that overhead also.

So rewrite your code so that it doesn't trigger the warning.  When you
get a warning, you're doing something that could be done in a better
way.  So don't whine about the performance.

It's a quality of implementation issue whether C code that tests for
issues that deserve warnings can do the test without slowing down code
that doesn't deserve a warning.  Ditto for standard library code.

Here's an example.  I expect there will eventually (not in 2.1 yet!)
warnings in the deprecated string module.  If you get such a warning
in a time-critical piece of code, the solution is to use string
methods -- not to while about the performance of the backwards
compatibility code.

--Guido van Rossum (home page: http://www.python.org/~guido/)