Re: [Python-Dev] Stdlib Logging questions (PEP 337 SoC)

2006-06-06 Thread A.M. Kuchling
On Mon, Jun 05, 2006 at 08:49:47PM -0400, Jim Jewett wrote: If no explicit changes are made locally, py.asyncore.dispatcher.hits py.asyncore.dispatcher.messages These handler names seem really specific, though. Why have 'dispatcher' in there? Part of Jackilyn's task should be to

Re: [Python-Dev] Stdlib Logging questions (PEP 337 SoC)

2006-06-06 Thread Jim Jewett
On 6/5/06, Phillip J. Eby [EMAIL PROTECTED] wrote: I notice you've completely avoided the question of whether this should be being done at all. As far as I can tell, this PEP hasn't actually been discussed. Please don't waste time changing modules for which there is no consensus that this

[Python-Dev] Stdlib Logging questions (PEP 337 SoC)

2006-06-06 Thread Jim Jewett
py.asyncore.dispatcher.hits py.asyncore.dispatcher.messages These handler names seem really specific, though. Why have 'dispatcher' in there? The existing logging that she is replacing is done through methods of the dispatcher class. The dispatcher class is only a portion of the

Re: [Python-Dev] Stdlib Logging questions (PEP 337 SoC)

2006-06-06 Thread Jeremy Hylton
On 6/6/06, Fredrik Lundh [EMAIL PROTECTED] wrote: Jim Jewett wrote: For pkgutil in particular, the change is that instead of writing to stderr (which can scroll off and get lost), it will write to the errorlog. In a truly default setup, that still ends up writing to stderr. umm. if

Re: [Python-Dev] Stdlib Logging questions (PEP 337 SoC)

2006-06-06 Thread skip
As far as I can tell, this PEP hasn't actually been discussed. Please don't waste time changing modules for which there is no consensus that this *should* be done. Jim Under a specific PEP number, no. The concept of adding logging to Jim the stdlib, yes, periodically.

Re: [Python-Dev] Stdlib Logging questions (PEP 337 SoC)

2006-06-06 Thread Fredrik Lundh
Jim Jewett wrote: The existing logging that she is replacing is done through methods of the dispatcher class. The dispatcher class is only a portion of the whole module. the dispatcher class is never used on its own; it's a base class for user-defined communication classes. asyncore users

Re: [Python-Dev] Stdlib Logging questions (PEP 337 SoC)

2006-06-06 Thread Jim Jewett
On 6/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I notice in the PEP that BaseHTTPServer is on the list of candidate modules. Please don't mess with anything that logs in the common Apache log format. There are lots of tools out there that munch on that sort of output. Changing it would

Re: [Python-Dev] Stdlib Logging questions (PEP 337 SoC)

2006-06-06 Thread Fredrik Lundh
Jim Jewett wrote: This does argue in favor of allowing the more intrusive additions to handlers and default configuration. It would be useful to have a handler that emitted only Apache log format records, and saved them (by default) to a rotating file rather than stderr.(And it *might* make

Re: [Python-Dev] Stdlib Logging questions (PEP 337 SoC)

2006-06-06 Thread Phillip J. Eby
At 10:13 AM 6/6/2006 -0400, Jim Jewett wrote: On 6/5/06, Phillip J. Eby [EMAIL PROTECTED] wrote: I notice you've completely avoided the question of whether this should be being done at all. As far as I can tell, this PEP hasn't actually been discussed. Please don't waste time changing modules

Re: [Python-Dev] Stdlib Logging questions (PEP 337 SoC)

2006-06-06 Thread A.M. Kuchling
On Tue, Jun 06, 2006 at 10:36:06AM -0400, Jim Jewett wrote: Are you suggesting that the logging module should ship with a standard configuration that does something specific for py.* loggers? Or even one that has different handlers for different stdlib modules? No, I meant some modules don't

Re: [Python-Dev] Stdlib Logging questions (PEP 337 SoC)

2006-06-06 Thread Greg Ewing
Jim Jewett wrote: For pkgutil in particular, the change is that instead of writing to stderr (which can scroll off and get lost), it will write to the errorlog. In a truly default setup, that still ends up writing to stderr. This might be better addressed by providing a centralised way of

Re: [Python-Dev] Stdlib Logging questions (PEP 337 SoC)

2006-06-05 Thread Fredrik Lundh
Phillip J. Eby wrote: If this *has* to be added to the modules that don't currently do any logging, can we please delay the import until it's actually needed? now that we've had a needforspeed sprint, it's clear that it's time to start working on slowing things down again ;-) I think it

Re: [Python-Dev] Stdlib Logging questions (PEP 337 SoC)

2006-06-05 Thread Jim Jewett
On 6/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Jim (2) Should NAME be module.__name__? Seems reasonable. (The clipped part was that the output will look a bit different when, say, the module is run as a script and the name is __main__). But if no one objects, I'll take this as a

[Python-Dev] Stdlib Logging questions (PEP 337 SoC)

2006-06-05 Thread Jim Jewett
On 6/4/06, Phillip J. Eby [EMAIL PROTECTED] wrote: can we please delay the import until it's actually needed? i.e., until after some logging option is enabled? I have asked her to make this change. I don't like the extra conditional dance it causes, but I agree that not wanting to log is a

[Python-Dev] Stdlib Logging questions (PEP 337 SoC)

2006-06-04 Thread Jim Jewett
Jackilyn is adding logging to several stdlib modules for the Google Summer of Code (PEP 337), and asked me to review her first few changes. There were a few comments that I felt I should double-check with Python-dev first, in case my own intuition is wrong. For reference, she is adding the

Re: [Python-Dev] Stdlib Logging questions (PEP 337 SoC)

2006-06-04 Thread skip
Jim (1) Should we ask Vinay Sajip to add a convenience function (for Jim getting the stdlib logger) to the logging module itself? -1. Jim (2) Should NAME be module.__name__? Seems reasonable. Jim (3) Should she put out a message when a (now logged) module is Jim

Re: [Python-Dev] Stdlib Logging questions (PEP 337 SoC)

2006-06-04 Thread Phillip J. Eby
At 09:27 PM 6/4/2006 -0400, Jim Jewett wrote: Jackilyn is adding logging to several stdlib modules for the Google Summer of Code (PEP 337), and asked me to review her first few changes. That PEP doesn't appear to have been approved, and I don't recall any discussion on Python-Dev. I also