[issue12174] Multiprocessing logging levels unclear
New submission from JJeffries jamesjeffries1@gmail.com:
It is unclear without reference to the logging module where the multiprocessing logging levels fit in the normal logging provided by the logging module, even though it says above the table
"The table below illustrates where theses fit in the normal level hierarchy.
+----------------+----------------+ | Level | Numeric value | +================+================+ | ``SUBWARNING`` | 25 | +----------------+----------------+ | ``SUBDEBUG`` | 5 | +----------------+----------------+"
I propose adding further values from the logging module for clarification.
---------- assignee: docs@python components: Documentation messages: 136839 nosy: JJeffries, docs@python priority: normal severity: normal status: open title: Multiprocessing logging levels unclear versions: Python 3.3
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue12174 _______________________________________
Petri Lehtinen petri@digip.org added the comment:
It seems that the documentation of logging no longer gives a table with numeric values for levels (I remember seeing it before). Maybe it would be most useful to remove the table from multiprocessing documentation and state it explicitly that "SUBDEBUG is lower than DEBUG and SUBWARNING is between INFO and WARNING".
---------- nosy: +petri.lehtinen
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue12174 _______________________________________
Changes by JJeffries jamesjeffries1@gmail.com:
---------- keywords: +patch Added file: http://bugs.python.org/file22106/multiprocessing_logging.patch
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue12174 _______________________________________
Petri Lehtinen petri@digip.org added the comment:
The patch is in an invalid format. See http://docs.python.org/devguide/patch.html for instructions on working with patches. If you cannot/won't use Mercurial, use two separate directories for original and modified cpython source tree, and invoke:
diff -urN cpython-orig cpython-modified
----------
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue12174 _______________________________________
Petri Lehtinen petri@digip.org added the comment:
Converted the patch by JJeffries to a valid format.
---------- Added file: http://bugs.python.org/file22110/multiprocessing_logging_2.patch
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue12174 _______________________________________
Changes by Nick Coghlan ncoghlan@gmail.com:
---------- nosy: +jnoller, ncoghlan
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue12174 _______________________________________
R. David Murray rdmurray@bitdance.com added the comment:
I think it would be good to mention the numeric levels in the text as well (in parenthesis, perhaps), unless the rest of the logging docs no longer refer to the numeric levels.
---------- nosy: +r.david.murray
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue12174 _______________________________________
Petri Lehtinen petri@digip.org added the comment:
R. David Murray wrote:
I think it would be good to mention the numeric levels in the text as well (in parenthesis, perhaps), unless the rest of the logging docs no longer refer to the numeric levels.
AFAICS, there are no numbers in the logging docs anymore.
----------
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue12174 _______________________________________
Changes by Petri Lehtinen petri@digip.org:
---------- keywords: +needs review stage: -> patch review versions: +Python 3.2
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue12174 _______________________________________
Vinay Sajip vinay_sajip@yahoo.co.uk added the comment:
Although the reference docs don't list the numeric values of logging levels, this happened during reorganising of the docs. The table has moved to the HOWTO:
http://docs.python.org/howto/logging.html#logging-levels
That said, I don't understand the need for special logging levels in the multiprocessing package. From the section following the one linked to above:
"Defining your own levels is possible, but should not be necessary, as the existing levels have been chosen on the basis of practical experience. However, if you are convinced that you need custom levels, great care should be exercised when doing this, and it is possibly *a very bad idea to define custom levels if you are developing a library*. That’s because if multiple library authors all define their own custom levels, there is a chance that the logging output from such multiple libraries used together will be difficult for the using developer to control and/or interpret, because a given numeric value might mean different things for different libraries."
---------- nosy: +vinay.sajip
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue12174 _______________________________________
Petri Lehtinen petri@digip.org added the comment:
Should there be another issue opened to do something about the extra logging levels?
----------
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue12174 _______________________________________
Vinay Sajip vinay_sajip@yahoo.co.uk added the comment:
Should there be another issue opened to do something about the extra logging
levels?
IMO they shouldn't have been added in the first place, but I'm not sure if they're part of the public API and hence subject to backward-compatibility constraints. It would be nice to hear a justification for them from Jesse (or someone else). Of course levels are a bit subjective and logging supports user-defined levels for special cases, but using multiple libs with different added levels would be a headache. I think at least the stdlib should stick to the standard levels.
----------
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue12174 _______________________________________
Camilla Montonen added the comment:
This issue raises the fact that the 2.X documentation lists two logging levels (SUBDEBUG and SUBWARNING) without explaining how these two fit into the logging hierarchy of the logging levels provided by the standard library logging module (ie, is SUBDEBUG between INFO and DEBUG).
The patch (provided by JJeffries and modified by Petri Lehtinen) adds an explanatory note stating the hierarchy as follows
These are :const:`SUBWARNING`, +which fits between :const:`INFO` and :const:`WARNING` in the normal logging +hierarchy, and :const:`SUBDEBUG`, which fits below :const:`DEBUG`
Review (this applies to the 2.X version of the documentation)
1. It would be nice to clarify that SUBDEBUG is between DEBUG and NOTSET instead of saying that it is 'below' as this maybe misunderstood (at least it's not very clear to me).
2. Slightly unrelated to the main issue of this patch
2a) "In addition to having these two logging functions, the multiprocessing also"
Should be
"In addition to having these two logging functions, the multiprocessing module also"
3. The documentation for the multiprocessing module in Python 3.X has removed any mention of SUBWARNING and SUBDEBUG, so I'm not sure if this patch is even relevant anymore?
4. Also, slightly tangent to this patch, but might be nice to pick up is the fact that documentation for the 2.X version mentions that the logging level table can be viewed in the logging module documentation
"For a full table of logging levels, see the logging module."
which is not the case anymore. As Vinay Sajip mentions, in 2.X the logging level table has moved to the how-to https://docs.python.org/2/howto/logging.html#logging-levels and so this link should be updated as well
TODO: 1. Check if SUBWARNING and SUBDEBUG are still part of the public API in 3.X and then suggest alterations to documentation based on that.
---------- nosy: +Winterflower
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue12174 _______________________________________
Changes by Davin Potts python@discontinuity.net:
---------- nosy: +davin
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue12174 _______________________________________
Vinay Sajip vinay_sajip@yahoo.co.uk added the comment:
I'd like to close this issue as out of date - anyone object?
----------
_______________________________________ Python tracker report@bugs.python.org https://bugs.python.org/issue12174 _______________________________________
Change by Irit Katriel iritkatriel@yahoo.com:
---------- resolution: -> out of date stage: patch review -> resolved status: open -> closed
_______________________________________ Python tracker report@bugs.python.org https://bugs.python.org/issue12174 _______________________________________
participants (8)
-
Camilla Montonen -
Davin Potts
-
Irit Katriel
-
JJeffries
-
Nick Coghlan
-
Petri Lehtinen
-
R. David Murray
-
Vinay Sajip