Ben Sizer schrieb:
> On Dec 9, 5:14 pm, Jorge Godoy <[EMAIL PROTECTED]> wrote:
>> Em Sunday 09 December 2007 11:54:14 Ben Sizer escreveu:
>>
>>> But is this the same object as above then? Neither the TG or the
>>> Python docs are clear on this. I don't understand what this string
>>> parameter corresponds to, if anything. The implication is that you get
>>> given a logger with that name, but that name doesn't match any of the
>>> logger names given in the ,cfg file, so what would you get? It's all
>>> very confusing!
>> There was a "testing123" on the configuration. It matches that one.
>
> Ok, so what's the difference between:
> log = logging.getLogger('testing123')
> and
> log = logging.getLogger('testing123.module_name')
>
> If they both get testing123, then why does the Python documentation
> imply that you get a different logger if you supply a different name?
> It's not very clear just what that name does. Why add the extra bit?
> The docs talk about a hierarchical structure, but what does it
> actually mean in this context?
>
>>> Is that one? It looks more like three! It seems like there isn't a
>>> consistent definition of what a 'logger' is.
>> Three?
>
> The config file has a section called [[loggers]]. It has 3 entries.
> Therefore, it makes sense to assume there are 3 loggers. But all the
> examples seem to expect you to just get one. It's not clear. Do you
> refer to them by different names? If so, why does a quick start
> project create them, and under what circumstances do you use the
> others? And does the hierarchical naming system apply to these - is
> that how you can access the first one when you use a name that only
> prefix-matches it?
>
> Oh, and comments in the docs like "(note the missing qualname)" with
> no explanation of why we're supposed to note that just serve to really
> confuse matters.
>
> I'm sure this is simple once you understand it, but it's actually
> quite confusing to try and read through all these things and try to
> work out what it's actually referring to. The documentation (not just
> TG, Python's too) is very vague.
I think the second paragraph in the logging-module docs is pretty clear:
"""
Logging is performed by calling methods on instances of the Logger class
(hereafter called loggers). Each instance has a name, and they are
conceptually arranged in a name space hierarchy using dots (periods) as
separators. For example, a logger named "scan" is the parent of loggers
"scan.text", "scan.html" and "scan.pdf". Logger names can be anything
you want, and indicate the area of an application in which a logged
message originates.
"""
http://docs.python.org/lib/module-logging.html
So the logger foo.bar is child to foo - and if you set levels for foo,
but not for foo.bar, the latter will inherit the logging level of it's
ancestor. But you can set foo.bar to a separate level.
And given that the TG docs state in the first paragraph that it uses the
logging-API, I don't see where it is vague. And the whole concept of
hierarchical loggers is explained here rather explicit IMHO
http://docs.python.org/lib/multiple-destinations.html
The config-file-format of the logging-module is somewhat awkward though
- the explicit declaring of loggers and formatters and handlers is odd.
Diez
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
