Hi, [Francois Pinard]
[holger krekel]
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.
Thanks for taking care.
[...] 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.
Good. There also is a growing number of pypy-usages of the log functionality but doing changes there should not be a big problem either.
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.
I think it's a very valid concern. So there should be some code path that makes this easy.
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...
Maybe we could add e.g. "autocr=True|False" somewhere to make this configurable.
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.
I share that dislike.
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.
The suggestion makes sense (inserting " " * len(prefix) after newlines in messages). Actually I would like to sit together with you for some hours sorting out usages/scenarios and designing the API accordingly. I also have a couple of more ideas of how py.log should fit with other usages like sending things remotely over py.execnet channels. Just to mention it already: i am thinking of doing a py lib hacking/sprinting session around Pycon US 2006. For the time being, I'd suggest that you get commit rights and we work commonly on some (non-main-page linked for now) feature descriptions/api scenarios in py/documentation/log.txt to sort out the goals. Implementing it is less of a deal, i think and we can first do it by introducing py.log2 until the API is settled/tested by real code. If you agree just send me your account name/ssh-key. Maybe Grig is also interested in participating in that effort. cheers, holger