[ python-Feature Requests-1190689 ] logging module '.' behavior
SourceForge.net
noreply at sourceforge.net
Thu Apr 28 09:21:32 CEST 2005
Feature Requests item #1190689, was opened at 2005-04-26 20:19
Message generated for change (Comment added) made by cxdunn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190689&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Dunn (cxdunn)
Assigned to: Vinay Sajip (vsajip)
Summary: logging module '.' behavior
Initial Comment:
I would like a trailing '.' to be ignored in names
passed to getLogger(), like a trainling '/' in a Unix path.
In module 'foo':
logfoo = getLogger('.foo.')
# logger '"" should be the parent of ".foo"
Elsewhere, controlled by the user of that module:
import foo
logdefault = getLogger('.')
hdlr = StreamHandler()
fmtr = Formatter("%(name)s:%(msg)s")
hdlr.setFormatter(fmtr)
logdefault.addHandler(hdlr)
Given this change, I would also like the name of the
default logger to be displayed as '.', or even "",
rather than 'root'. The current behavior is odd:
logfoo.info("Foo message")
displays
.foo:Foo message
buf
logdefault.info("Default message")
displays
root:Default message
I NEVER mentioned the word "root" anywhere! And I don't
think it's very descriptive.
I would rather see ANY of these:
:Default message
.:Default message
default:Default message
logging:Default message
These changes would make the system more intuitive.
-cxdunn
----------------------------------------------------------------------
>Comment By: Christopher Dunn (cxdunn)
Date: 2005-04-28 02:21
Message:
Logged In: YES
user_id=1267419
I am attaching a first pass it it.
I've stored the "absolute" names everywhere, including both
leading and trailing '.'
I call this "absolute" by analogy with os.path.abspath(). I
believe that similarities within the Python library help the
user remember key concepts.
What's missing:
* I don't have aliases.
* The "current working logger" is always '.'
* And I haven't added any extra tags for the Formatter.
But those are all very simple changes. The tough part is
getting the path-searching correct. I have a big UnitTest
suite which I can send to you if you'd like.
The most important thing is that the word "root" is
completely gone, but perhaps %(name)s should translate '.'
to 'root' for backwards compatibility.
The second-most important thing is that getLogger('.')
returns the root logger.
Third is that getLogger("Package.Module") is equivalent to
getLogger(".Package.Module.")
As for tags in the Formatter, after some testing I suggest
these:
%(name)s => abspath.rstrip('.'), but "." becomes "root"
%(absname)s => abspath, with leading AND trailing dot, like
a directory, so there is no question about whether the root
displays as "." or "". It is always just dot in absolute
notation.
%(logger)s => abspath.rstrip('.'), maybe the prettiest
I must tell you that, once I figured out how the logging
module works, I really love it!
Other possible additions:
* Some useful, predefined filter classes: Never, OneTime
(which must have a reset() method to clear its cache). I can
send my version if you want.
* A PipedStreamHandler. I'm not sure how to make this work.
The idea is that, in UnitTesting, I want to read from some
stream immediately after an operation, and I want the logged
data to be immediately available, but to disappear as soon
as I've read it. Does that make sense? Right now, I use a
cStringIO object, with s.seek(0); s.truncate() after every read.
-cxdunn
----------------------------------------------------------------------
Comment By: Christopher Dunn (cxdunn)
Date: 2005-04-27 15:37
Message:
Logged In: YES
user_id=1267419
Novices always ask, "Why did it print 'root'? Where did that
come from?
After discussing this with some other "logging" module
users, I think we've come up with a very good idea, which
would maintain BACKWARDS COMPATIBILITY.
Essentially, treat the logging module as a shell and the
logger name as a path. Specifically,
* Let the global logging functions operate on the "current
worrking logger", which by default is "." (Let "root" be an
alias for ".")
* Change getLogger() so that it works on both absolute and
relative logger paths. (Since the default current logger is
"root", we maintain backwards compatibility.)
* Change the format function so that %(name)s shows the
relative path, if the absolute path starts with the current
working logger name.
* Add a format keyword, %(absname)s, which prints the
absolute logger path.
* Add another format keyword, %(logger)s, which prints what
most people expect to see: the absolute logger name, sans
the leading dot. (The "root" or "." logger would display as
"", exactly the way it is usually accessed.)
* Add global functions, change_current_logger() and
get_current_logger().
* Add global function, alias(). Always create an alias for
"root" to "."
Examples::
from logging import *
log = getLogger() #or getLogger(".") or getLogger("root")
h1 = StreamHandler()
f1 = Formatter("[%(name)s]%(message)s")
h1.setFormatter(f1)
log.addHandler(h1)
h2 = StreamHandler()
f2 = Formatter("[%(absname)s]%(message)s")
h2.setFormatter(f2)
log.addHandler(h2)
h3 = StreamHandler()
f3 = Formatter("[%(logger)s]%(message)s")
h3.setFormatter(f3)
log.addHandler(h3)
log.error("First message")
# ...
child = getLogger("child") # or getLogger(".child")
child.error("Bad news")
This should print:
[root]First message
[.]First message
[]First message
[child]Bad news
[.child]Bad news
[child]Bad news
This would create tremendous flexibility, add some clarity
to the meaning of the "root" logger, and still maintain
complete backwards compatibility.
I am willing to make the changes myself, including
UnitTests, if there is agreement that they would be adopted.
(Note that String.before() and String.after() would make the
coding a little easier/clearer, but that's a different
feature request.)
-cxdunn
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1190689&group_id=5470
More information about the Python-bugs-list
mailing list