Re: Unification of logging in Python's Standard Library

Discussion in 'Python' started by Skip Montanaro, Aug 19, 2003.

  1. Matthew> With the inclusion of the new 'logging' module in Python 2.3,
    Matthew> I'm wondering whether there are plans to update the rest of the
    Matthew> Standard Library to use this module wherever there is logging
    Matthew> to be done.
    ...
    Matthew> A single, unified logging system across the entire Python
    Matthew> Standard Library would be a worthy goal for some future release
    Matthew> (Python 3000, or maybe even 2.4/2.5?).

    Rather than bring it up on python-dev as Alex suggested (I think it might
    get lost there as well), I think you should open a bug report on SF which
    identifies the problem and which modules you think need to be updated. This
    provides a record of how people think this task should be approached. As
    time goes on, patches for specific modules can be attached to the report and
    incorporated into the modules in question.

    Another alternative is to write a PEP, though I don't think this is
    necessarily required for this particular task. It also presents a higher
    barrier to action than a bug report.

    Skip
     
    Skip Montanaro, Aug 19, 2003
    #1
    1. Advertising

  2. On Tue, 19 Aug 2003 10:06:26 -0500,
    Skip Montanaro <> wrote:
    > Matthew> A single, unified logging system across the entire Python
    > Matthew> Standard Library would be a worthy goal for some future release
    > Matthew> (Python 3000, or maybe even 2.4/2.5?).
    > Another alternative is to write a PEP, though I don't think this is
    > necessarily required for this particular task. It also presents a higher
    > barrier to action than a bug report.


    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.

    --amk
     
    A.M. Kuchling, Aug 19, 2003
    #2
    1. Advertising

  3. Skip Montanaro

    Paul Moore Guest

    Skip Montanaro <> writes:

    > Matthew> With the inclusion of the new 'logging' module in Python 2.3,
    > Matthew> I'm wondering whether there are plans to update the rest of the
    > Matthew> Standard Library to use this module wherever there is logging
    > Matthew> to be done.
    > ...
    > Matthew> A single, unified logging system across the entire Python
    > Matthew> Standard Library would be a worthy goal for some future release
    > Matthew> (Python 3000, or maybe even 2.4/2.5?).
    >
    > Rather than bring it up on python-dev as Alex suggested (I think it might
    > get lost there as well), I think you should open a bug report on SF which
    > identifies the problem and which modules you think need to be updated. This
    > provides a record of how people think this task should be approached. As
    > time goes on, patches for specific modules can be attached to the report and
    > incorporated into the modules in question.
    >
    > Another alternative is to write a PEP, though I don't think this is
    > necessarily required for this particular task. It also presents a higher
    > barrier to action than a bug report.


    One other point, which is worth mentioning (although don't let it put
    you off reporting a bug or writing a PEP), is that something like this
    is *far* more likely to happen if you contribute code rather than just
    ideas.

    If you haven't the expertise or time to contribute code, please still
    raise the idea - but don't be too disappointed if it's hard to get
    anyone to do anything about it.

    If you *can* contribute code, then you'll be welcomed with open arms
    of course. And your code will be ripped to shreds, but that's just to
    show we all care :)

    Paul.
    --
    This signature intentionally left blank
     
    Paul Moore, Aug 19, 2003
    #3
    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. John Roth
    Replies:
    3
    Views:
    308
    Duncan Booth
    Aug 20, 2003
  3. David MacQuigg

    Unification of Methods and Functions

    David MacQuigg, Apr 30, 2004, in forum: Python
    Replies:
    133
    Views:
    2,014
    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,401
    Andrew Dalke
    Oct 31, 2004
Loading...

Share This Page