On 07 November 2000, Guido van Rossum said:
> > Or it could be just a string. The main point is that filtering on a
> > number or enum is not flexible enough.
>
> OK, let's make this a class then. Just keep exceptions out of it
> -- this is a separate, disjoint set of classes. Let's call this
> "warning category". There will be standard categories and user code
> can add categories.
This sounds right -- I was going to suggest "warning class" instead of
"level", but "category" might be a better word. My main rationale was
filtering: show me "integer divide" problems, but don't bother me with
"function argument not used". (Hmm, those two sound more like specific
warnings rather than warning categories. Probably the categories there
would be "arithmetic" and "dataflow".)
> > I would prefer something easier to spell and with more of a central "you
> > should use this alot" feeling.
>
> OK, let's make this a built-in: warning(category, message).
Minor spelling nit: I would call it 'warn()' (or 'sys.warn()', or
'Py_Warn()', etc.) since that's a verb.
More importantly: if 'warn(ing)' is meant to be used mainly for
compiler-style warnings -- you're using this language or library feature
inappropriately -- then it should be left in sys. But if it's meant to
also be used for printing some message to stderr (like Perl's 'warn'),
then there's a good case for making it a builtin.
Almost every Python script I write features
def warn (msg):
sys.stderr.write("warning: " + msg + "\n")
That might be a clue that something (albeit a tiny thing) is missing
from the language. ;-)
Greg
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