[holger krekel]
Hi Francois!
Hi Holger, and thanks for replying!
Actually the logging API is still quite experimental so your feedback is most welcome.
You did open the door! :-) I fetched py-dev@codespeak.net archives a few hours ago, but it will take some time before I become acquainted with them, so I may raise issues which have already been discussed, I do not know yet.
[...] But for the time being, i'd suggest just forgetting about py.log.get() and sticking to the more documented approach.
OK. In any case, the code base for our big application is likely to be boiling at least for the next six months or so, so changes are always possible on our side for quite a while, without being hurtful. Let me start the discussion on the following issue. It is a common and useful idiom, where I work most of the time, to pass a ``write`` argument to various functions, letting the caller decide what ``write`` will do in any particular case. It could be an opened file, the input side of a service process, the ``append`` method of a list, or God knows what else. It would be convenient being able to merely pass a logger for that ``write`` argument, hoping this would yield a sensible behaviour. This comes with problems, however. Currently, py.log and the standard logging module both provide a newline after the text to be logged. If I provide a newline at the end of a text given to a py.log logger, this will create a spurious white line. Whether a logger should remove trailing newlines or not, is debatable. For one, I would be willing and ready to always provide the trailing newline in my calls, given I expect the logger to add none, so logging functions and ``write`` functions are more fully interchangeable. However, tradition is that logging functions turn incomplete lines into complete lines. I do not know where lies the greater wisdom... Another point, which is pretty factual in our code base, is that the application often logs multi-line texts, which are then (of course) displayed on many lines. I really dislike runs of stars or hyphens for creating visual blocks out of such log messages. Currently, py.log merely transmits embedded newlines as is, so the output is a bit unclear about if a line is part of the log message, or not. A multi-line logged message might neatly insert a white margin to the left of all lines except the first, with the margin length being equal to the size of the prefix (shown between square brackets) found on the first line. This (different prefix, different margins) would be more legible, I think, than a fixed margin size -- yet we might theoretically imagine bad effects from very long prefixes, all unlikely that they can be. -- François Pinard http://pinard.progiciels-bpi.ca