Hi, IMHO the prior decision(s) are too conservative. Reading the bugs, we can
see lots of folks reinventing the wheel with common use cases for no good
reason. I also gave examples in the log4j, docs, and web apps world that these
levels are recognized needs.
An addition would represent a very tiny fractional increase in the complexity of
the logging module, from ~6 to ~8 in one small corner. It's not like we're
adding human expressions to cats and piles of poo here are we? ;-)
The builtin java logging suffers from backwards compatibility with an awkward
initial design. log4j doesn't (nor we) have that problem, but it includes some
cases suggested.
In short, have been using note and fatal for years productively. Not a strong
proponent of trace and have survived without it so far, but if it were there I'd
have used it a few times over the years.
On 2017-11-28 12:17, Serhiy Storchaka wrote:
28.11.17 21:45, Guido van Rossum пише:
These look like good improvements. I think you should make an issue on
bugs.python.org <http://bugs.python.org> describing your proposal and if you
can submit a PR that implements it.
See https://bugs.python.org/issue31732
It was discussed and rejected. Citing Raymond: "Overall, this seems rehash and
second guess the discussions and decisions made 15 years ago when PEP 282 was
accepted."
The set of logging levels is not closed. The user can extend it to cover more
specialized uses by logging.addLevelName(). There are disadvantages of having
too much standard names for logging levels (as we can see in Java).
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
