On Mon, Dec 11, 2000 at 07:39:31PM -0500, Guido van Rossum wrote:
> > Since you must do "from warnings import warn" before using the warnings,
> > then I think it makes sense to put the Warning classes into the warnings
> > module. (e.g. why increase the size of the builtins?)
>
> I don't particularly care whether the Warning category classes are
> builtins, but I can't declare them in the warnings module. Typical
> use from C is:
>
> if (PyErr_Warn(PyExc_DeprecationWarning,
> "the strop module is deprecated"))
> return NULL;
>
> PyErr_Warn() imports the warnings module on its first call. But the
> value of PyExc_DeprecationWarning c.s. must be available *before* the
> first call, so they can't be imported from the warnings module!
Do the following:
pywarn.h or pyerrors.h:
#define PyWARN_DEPRECATION "DeprecationWarning"
...
if (PyErr_Warn(PyWARN_DEPRECATION,
"the strop module is deprecated"))
return NULL;
The PyErr_Warn would then use the string to dynamically look up / bind to
the correct value from the warnings module. By using the symbolic constant,
you will catch typos in the C code (e.g. if people passed raw strings, then
a typo won't be found until runtime; using symbols will catch the problem at
compile time).
The above strategy will allow for fully-delayed loading, and for all the
warnings to be located in the "warnings" module.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
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