Nick Coghlan <ncoghlan <at> gmail.com> writes:
> The switching between percent, str.format and string.Template
> formatting. It turns out that has been documented, but the table in
> question is still written from a percent-style formatting point of
> view.
Oh, right - yes. I presume you mean the table in the formatter documentation
which shows %(message)s etc.
> The "lazy" stream handler might be useful to make public in some way.
> For example, rather than hardcoding sys.stderr, it could take a
> callable that it uses to retrieve the stream. That kind of change can
> wait until 3.3 though - what is there now should be fine to let us get
> concurrent.futures and the logging tests to play nicely together.
Actually if we're to change things to print INFO to stdout and WARNING+ to
stderr, I'd change the last resort handler class to be more than just defining
a lazy stream property: perhaps something like [untested]
class _DefaultHandler(StreamHandler):
def __init__(self, level=NOTSET):
"""
Initialize the handler.
"""
Handler.__init__(self, level)
def emit(self, record):
if record.levelno == INFO:
self.stream = sys.stdout
else:
self.stream = sys.stderr
super(_DefaultHandler, self).emit(record)
> As far as whether anything else in the logging defaults needs to
> change, I don't think so. I'm now happy that if an application needs
I agree it can be refined later, but if we agreed that INFO goes to stdout,
then something like the above could be put in place for 3.2 (perhaps 3.2b2).
> output defaults to sys.stderr" philosophy). The change to the default
> behaviour was just to make logging.warning() etc a suitable
> replacement for writing directly to sys.stderr when exceptions can't
> be raised, which is in keeping with the existing spirit of the logging
> module.
Agreed.
> I don't think we should be adding more *code* at this stage. But
> documentation fixes and adjustments may be a good idea. I've learned
> quite a bit myself about the logging module in the course of this
> discussion, so it would be nice if some of that could be captured and
> used to improve the documentation.
Yes, you (and Glenn, and others) have given me quite a bit to work on, on that
score!
> That said, something that might be interesting is to see what my
> addHandler() recipe [1] would do for the examples in the logging
> documentation. If it makes a big enough difference, then it may be
> worth talking to Georg about adding it, even for 3.2. Alternatively,
> if you like the idea, but we don't want to break the feature freeze
> for it, then it may make a nice "see-also" link from the docs. I find
> it useful from a "here are all the things I can configure on a handler
> in one easy bundle" point of view, even aside from any benefits in
> reduced typing.
Actually I've been thinking about a handlers= optional argument for basicConfig
for some time (which, if provided, would override file and stream arguments).
But it seemed a little unwieldy and came across plainly as the afterthought it
admittedly was :-)
Regards,
Vinay Sajip
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
