On Sat, Dec 11, 2010 at 4:18 PM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote: >> formatting (when the documentation for the new styles feature goes in >> would probably be an appropriate time to fix this). Similarly, the > > Sorry, what do you mean by "new styles feature"?
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. >> Anyway, the shortest way I could find of setting this up (debug > > Yes, except that you could have set the root logger level to INFO rather than > DEBUG. > > This raises some more questions. Obviously, we don't want users to have to go > through these steps themselves. Once these steps have been finalised, the last > resort handler could be modified to do all this. Should this handler be part > of > the public API, so that it can be inherited from 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. 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 to emit text on stdout as part of its normal operation, then that isn't what the logging module is for - logging messages are intended to record "this happened, then that happened, then this other thing happened". They are *not* properly part of an application's console UI (which is reflected in the whole "silent by default" and "console 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. > I realise we're in beta and hence feature freeze ... just sayin'. We're all > consenting adults here, after all :-) 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. 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. Cheers, Nick. [1] http://code.activestate.com/recipes/577496-simple-creation-configuration-and-installation-of-/ -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
