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 o
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.
A related question: Will your student try to resolve the issues on SF
referring to logging, or is that not part of the project? There
> 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?
Sorry I'm a little late in to the discussion :-(
I can see people objecting to a "standa
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'
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 changi
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*
>
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 wo
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 user
>> 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, periodical
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.
>
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 pkgutil fails to open a pkg file, isn't it rather like
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 t
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 r
At 09:04 PM 6/5/2006 -0400, Jim Jewett wrote:
>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 da
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
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
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 coul
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
18 matches
Mail list logo
