Consistent logging in the standard library
A recent thread has discussed integrating logging with the rest of the standard library. Among other things, a question has arisen about what logging channel names standard library modules should use, and possible clashes with channel names used by applications. I'd like to propose that some portion of the namespace be reserved for use by logging in the standard library. If acceptable, all that would need to be done would be to update the documentation to indicate the namespace reservation. The actual use of the namespace could be implemented as and when each module is changed to use the logging module. The scheme of having all standard library logging under one umbrella allows applications to be configured so that all library-level messages can be routed to specific handlers, filtered simply at one point, etc. My preference for namespace reservation is that any logger name beginning with "python." should be reserved for use by the standard distribution. I think that each module should use an eponymous logging channel name rooted in the hierarchy for the Python library - e.g. asyncore would use "python.asyncore", etc. Matthew Barnes, who kicked off the original thread, prefers "stdlib" as the prefix to use, rather than "python". Comments, please! Vinay Sajip
On Wed, 2003-09-17 at 17:43, Vinay Sajip wrote:
Matthew Barnes, who kicked off the original thread, prefers "stdlib" as the prefix to use, rather than "python".
What about _ (underscore)? One of my half-baked totally unoriginal PEP ideas for Python 2.4 would be a syntax for forcing imports from the standard library. E.g. say I have a foo package, and inside there I've got a foo/logging.py module. Say there's also a foo/bar.py module and it wants to import the global logging package. How can it do that? "import logging" does a relative import. So the idea would be to be able to write "import _.logging" and definitely get the global logging package. Using underscore in the logger would mirror this mnemonic for globalness. -Barry
Barry> So the idea would be to be able to write "import _.logging" and Barry> definitely get the global logging package. Using underscore in Barry> the logger would mirror this mnemonic for globalness. The connection seems tenuous, at best. If I log messages to syslog and and that file is later viewed or summarized by a third party, "python" seems a lot more useful than "_" or even "stdlib". Skip
Skip Montanaro said:
Barry> So the idea would be to be able to write "import _.logging" and Barry> definitely get the global logging package. Using underscore in Barry> the logger would mirror this mnemonic for globalness.
The connection seems tenuous, at best. If I log messages to syslog and and that file is later viewed or summarized by a third party, "python" seems a lot more useful than "_" or even "stdlib".
I agree with Barry that a name should be given to the standard library "package" and that the namespace reserved in the logging hierarchy for standard library modules should match this name. On the other hand, "_" is making me have unpleasant Perl flashbacks. *shiver* So I also agree with Skip that something more verbose would be more useful. I'm okay with waiting to see what becomes of Barry's idea before deciding on a logging namespace. Barry: Not to get too far off-topic, but I'm curious what this statement would do: from _ import * And was this notation ever considered? import .logging (Not that that would help us much with the logging namespace issue. :-) Matthew Barnes
On Wed, 2003-09-17 at 20:22, Matthew F. Barnes wrote:
Not to get too far off-topic, but I'm curious what this statement would do:
from _ import *
I don't know. Perhaps Lib should have an __init__.py that would export an __all__?
And was this notation ever considered?
import .logging
It just was! :)
(Not that that would help us much with the logging namespace issue. :-)
No, but maybe they shouldn't be tied. Unless they should <wink>. I just wanted to bring it up because it seemed somewhat related and I've been meaning to write a PEP on forced global imports for Python 2.4. -Barry
Barry> So the idea would be to be able to write "import _.logging" and Barry> definitely get the global logging package. Using underscore in Barry> the logger would mirror this mnemonic for globalness.
Skip> The connection seems tenuous, at best. If I log messages to syslog and and Skip> that file is later viewed or summarized by a third party, "python" seems a Skip> lot more useful than "_" or even "stdlib". I agree. Readability in logs is the most important consideration here, and I think a scheme such as "python." + <modulename> makes it very clear where an event originated. Of course this would just be a prefix; a module could log to any name under this namespace, e.g. "python.asyncore.socket" for socket-related events in asyncore. Vinay
Vinay Sajip said:
I agree. Readability in logs is the most important consideration here, and I think a scheme such as "python." + <modulename> makes it very clear where an event originated. Of course this would just be a prefix; a module could log to any name under this namespace, e.g. "python.asyncore.socket" for socket-related events in asyncore.
I'm convinced. I'll work the "python" prefix into the proposal. Matthew Barnes
To recap recent discussion on this thread, there seems to be consensus among those I've spoken to that there should be a namespace in the logging hierarchy named "python" that is reserved for the standard library, and that standard library modules and packages should use loggers within this namespace that are named after themselves (i.e. "python." + __name__). For example, the asyncore module should use a logger named "python.asyncore". The modules may also define child loggers as needed, such as "python.asyncore.socket". This week's topic: Configuration I tend to think that, at least for Python 2.4, each logger should be configured to mimic the behavior of the Python 2.3 version of its corresponding module in terms of message format and destination (e.g. log-file, sys.stdout, sys.stderr, etc.). I think it would be nice for each "standard library logger" to default to such a configuration automatically, while still allowing a configuration file to customize them. The issue is where this default configuration should reside and when it should be applied. My reference implementation currently has each module configure its own logger at the end of the module, so that those statements are executed when the module is imported. But I'm not confident that this is the best approach, or even a correct approach. For example, consider what would happen if a configuration file that defines a section for the python.asyncore logger is processed *before* the asyncore module is imported. I'm looking for some helpful suggestions from the community. - What's the best approach for configuring the "standard library loggers", or should we at all? - Should the standard library define its own logging configuration file, and what would be the semantics around that? - Perhaps the logging API should provide for a way to test whether a particular logger is defined, so that the modules could check that before applying their default settings? Matthew Barnes
Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
I'd like to propose that some portion of the namespace be reserved for use by logging in the standard library. If acceptable, all that would need to be done would be to update the documentation to indicate the namespace reservation. The actual use of the namespace could be implemented as and when each module is changed to use the logging module.
The scheme of having all standard library logging under one umbrella allows applications to be configured so that all library-level messages can be routed to specific handlers, filtered simply at one point, etc.
I agree with this and was infact about to propose this to Matthew Barnes a short while ago. Good thing I read the list first. :-)
My preference for namespace reservation is that any logger name beginning with "python." should be reserved for use by the standard distribution. I think that each module should use an eponymous logging channel name rooted in the hierarchy for the Python library - e.g. asyncore would use "python.asyncore", etc.
Matthew Barnes, who kicked off the original thread, prefers "stdlib" as the prefix to use, rather than "python".
No strong preference either way, but if someone were to hold a gun to my head, I'd scream... And then express my preference for 'python' as the root. But that's just the Java talking :-) --Arsalan
I've accidently sent two slightly different emails on the same topic... Read the one timestamped 6:15 am. I know; my bad. No cookies for me for the next 24 hours... --Arsalan
Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
I'd like to propose that some portion of the namespace be reserved for use by logging in the standard library. If acceptable, all that would need to be done would be to update the documentation to indicate the namespace reservation. The actual use of the namespace could be implemented as and when each module is changed to use the logging module.
The scheme of having all standard library logging under one umbrella allows applications to be configured so that all library-level messages can be routed to specific handlers, filtered simply at one point, etc.
I agree with this and was infact about to propose this to Matthew Barnes a short while ago. Good thing I read the list first. :-)
My preference for namespace reservation is that any logger name beginning with "python." should be reserved for use by the standard distribution. I think that each module should use an eponymous logging channel name rooted in the hierarchy for the Python library - e.g. asyncore would use "python.asyncore", etc.
Matthew Barnes, who kicked off the original thread, prefers "stdlib" as the prefix to use, rather than "python".
No strong preference either way, but if someone were to hold a gun to my head, I'd scream... And then express my preference for 'python' as the root. But that's just the Java talking :-) Someone proposed an '_'. I don't know. My gut feeling is that it's too cryptic and Perl like. If you must have something, call it 'base' or 'python' or even 'stdlib'. But what do I know... --Arsalan
participants (5)
-
Arsalan Zaidi -
Barry Warsaw -
Matthew F. Barnes -
Skip Montanaro -
Vinay Sajip