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

[holger krekel]

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 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.

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