Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   Re: Unification of logging in Python's Standard Library (http://www.velocityreviews.com/forums/t321197-re-unification-of-logging-in-pythons-standard-library.html)

Skip Montanaro 08-19-2003 03:06 PM

Re: Unification of logging in Python's Standard Library
 

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



A.M. Kuchling 08-19-2003 04:18 PM

Re: Unification of logging in Python's Standard Library
 
On Tue, 19 Aug 2003 10:06:26 -0500,
Skip Montanaro <skip@pobox.com> 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.asy ncore'))?

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

Paul Moore 08-19-2003 07:38 PM

Re: Unification of logging in Python's Standard Library
 
Skip Montanaro <skip@pobox.com> 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


All times are GMT. The time now is 04:41 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.