[py-dev] Hi! And py.log :-)

[François Pinard]

[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 at 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