Re: Unification of logging in Python's Standard Library

Discussion in 'Python' started by John Roth, Aug 19, 2003.

  1. John Roth

    John Roth Guest

    "Matthew Barnes" <> wrote in message
    news:...
    > With the inclusion of the new 'logging' module in Python 2.3, I'm
    > wondering whether there are plans to update the rest of the Standard
    > Library to use this module wherever there is logging to be done. I
    > can think of a few Standard Library modules off the top of my head
    > that currently "roll their own" logging system:
    >
    > asyncore.py
    > BaseHTTPServer.py
    > cgi.py
    > doctest.py
    > imaplib.py
    > unittest.py
    >
    > A single, unified logging system across the entire Python Standard
    > Library would be a worthy goal for some future release (Python 3000,
    > or maybe even 2.4/2.5?).


    I'm going to agree with Andrew: write a PEP.

    Unittest, as far as I know, doesn't have a logging system, and
    I, for one, don't want to see it burdened with a completely unnecessary
    logging system. I can't comment on the other examples in your
    list because I've never used them, but unittest is part of my standard
    project life, and I like it the way it is, thanks. Kent Beck and the
    other people involved in the xUnit development put a lot of thought
    into how it works, and AFKC, lack of logging isn't one of the problems.

    John Roth
     
    John Roth, Aug 19, 2003
    #1
    1. Advertising

  2. "A.M. Kuchling" <> wrote>:
    > I suspect a PEP is required, because there are more issues here than just
    > changing sys.stderr.write() to logging.info(). For example, what logger
    > should modules use to log messages? If they use the root logger, it will be
    > difficult to discard messages from asyncore while keeping messages from the
    > ZODB. If they use a particular logger, how is this name chosen? Is it
    > dependent on the module name, so asyncore logs to 'asyncore' and so forth?
    > What if my application has a logger named 'network', and I want it to go to
    > 'network.asyncore', 'database.ZODB', etc.?
    >
    > If the user specifies a logger, how is this done? Does every public method
    > have to grow an optional 'log' argument, or is there a module-level global
    > setting, so you'd call
    > asyncore.set_logger(logging.getLogger('network.asyncore'))?
    >
    > None of these options are very difficult to implement, but choosing which
    > one will take some care; otherwise we'll be saddled with an inconvenient
    > implementation that we'll be forever working around.



    "John Roth" <> wrote:
    > I'm going to agree with Andrew: write a PEP.
    >
    > Unittest, as far as I know, doesn't have a logging system, and
    > I, for one, don't want to see it burdened with a completely unnecessary
    > logging system. I can't comment on the other examples in your
    > list because I've never used them, but unittest is part of my standard
    > project life, and I like it the way it is, thanks. Kent Beck and the
    > other people involved in the xUnit development put a lot of thought
    > into how it works, and AFKC, lack of logging isn't one of the problems.



    Andrew raised some very good points, and a PEP probably is necessary.
    I did have some half baked ideas on how to go about this.

    Generally speaking, the default logging output of each module that
    uses 'logging' should be identical or as identical as possible to what
    the module currently produces. This would (hopefully) make the
    transition nearly transparent to end-users. Then we provide some
    'hook' at either a module-level or (preferably) class-level for
    replacing the default logger with a customized one.

    Here's a few more module-specific thoughts:

    asyncore.py
    -----------
    Add a 'logger' attribute to the 'dispatcher' class, which defaults to
    a logger named 'asyncore' (i.e. the module's __name__) configured to
    use a StreamHandler. This would allow each instance of
    asyncore.dispatcher to potentially have a unique logger.

    BaseHTTPServer.py
    -----------------
    Add a 'logger' attribute to the 'BaseHTTPRequestHandler' class, which
    defaults to a logger named 'BaseHTTPServer' (i.e. the module's
    __name__) configured to use a StreamHandler and a Formatter that
    produces the RFC931-style messages that are currently produced (note:
    haven't looked into whether a logging.Formatter can do that). This
    would allow each instance of BaseHTTPServer.BaseHTTPRequestHandler to
    potentially have a unique logger.

    cgi.py
    ------
    Not quite sure about what to do with this one; Andrew's questions pop
    up here. Perhaps provide a logger named 'cgi' (i.e. the module's
    __name__) configured to use a StreamHandler. The functions should use
    a module-level 'logger' variable (initialized to the 'cgi' logger)
    rather than hard-coding the logger name into the function bodies. The
    'logger' variable could then be assigned a different logger instance
    and the functions would pick up on it.


    I need to kill some more brain cells on the other modules in my list.
    I will say that unittest is what motivated me to suggest this in the
    first place, since I'm working on a testing framework that is
    attempting to take advantage of both the unittest *and* logging
    modules. Perhaps a new TestRunner class that uses logging
    (LoggingTestRunner?) might coexist with the default TextTestRunner.

    Matt
     
    Matthew Barnes, Aug 20, 2003
    #2
    1. Advertising

  3. John Roth

    John Roth Guest

    "Matthew Barnes" <> wrote in message
    news:...

    > I will say that unittest is what motivated me to suggest this in the
    > first place, since I'm working on a testing framework that is
    > attempting to take advantage of both the unittest *and* logging
    > modules. Perhaps a new TestRunner class that uses logging
    > (LoggingTestRunner?) might coexist with the default TextTestRunner.


    Perhaps you could tell us a bit more about this? My usage of
    unittest is (relatively) pure XP/TDD - I expect all of the tests
    to pass except the last one I worked on, and when they don't,
    I swat it immediately. Consequently, I don't see any need for
    logging anything.

    John Roth

    >
    > Matt
     
    John Roth, Aug 20, 2003
    #3
  4. John Roth

    Duncan Booth Guest

    "John Roth" <> wrote in
    news::

    >> I will say that unittest is what motivated me to suggest this in the
    >> first place, since I'm working on a testing framework that is
    >> attempting to take advantage of both the unittest *and* logging
    >> modules. Perhaps a new TestRunner class that uses logging
    >> (LoggingTestRunner?) might coexist with the default TextTestRunner.

    >
    > Perhaps you could tell us a bit more about this? My usage of
    > unittest is (relatively) pure XP/TDD - I expect all of the tests
    > to pass except the last one I worked on, and when they don't,
    > I swat it immediately. Consequently, I don't see any need for
    > logging anything.
    >


    I would find it interesting, and possibly even useful, if unittest could be
    made to record some historical information in a database. e.g. The date and
    time when each unit test first failed, first passed, and most recently
    failed/passed, and the number of times each test has passed/failed. A
    record of the #lines of code each time the tests all pass would also be
    useful, and you probably want to record the stats separately against each
    developer.

    On a project with several developers (or one undisciplined one like myself)
    you could potentially use these figures to flag problems, such as someone
    whose tests usually pass first time is probably doing test last rather than
    test first coding, or if a lot of new code appears without new tests it was
    either a major refactor or someone isn't writing the tests they need.
    Someone who is doing it properly will show a pattern of at least three test
    runs (one fail, two passes) for each new test. Finally, should you survive
    lynching by the developers, the customer will be really pleased to see
    complicated graphs showing how much testing you are doing.

    Of course, this is completely unrelated to the sort of logging the logging
    module could do for you.

    --
    Duncan Booth
    int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
    "\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
     
    Duncan Booth, Aug 20, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rim
    Replies:
    3
    Views:
    306
    Moshe Zadka
    Jul 14, 2003
  2. Skip Montanaro
    Replies:
    2
    Views:
    306
    Paul Moore
    Aug 19, 2003
  3. David MacQuigg

    Unification of Methods and Functions

    David MacQuigg, Apr 30, 2004, in forum: Python
    Replies:
    133
    Views:
    2,009
    Duncan Booth
    Jun 1, 2004
  4. Delaney, Timothy C (Timothy)

    RE: Unification of Methods and Functions

    Delaney, Timothy C (Timothy), May 11, 2004, in forum: Python
    Replies:
    6
    Views:
    323
    David MacQuigg
    May 12, 2004
  5. kartik

    int/long unification hides bugs

    kartik, Oct 25, 2004, in forum: Python
    Replies:
    83
    Views:
    1,395
    Andrew Dalke
    Oct 31, 2004
Loading...

Share This Page