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

[Grig Gheorghiu]

Hi, Francois and Holger

(have been pretty busy during the weekend, so I'm only now reading this
thread...)

--- holger krekel <hpk at trillke.net> wrote:

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

This should indeed be pretty easy to implement.

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

I agree.

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

I think the more usage scenarios we have, the better the py.log API
will get. Maybe we can chat on IRC one day.

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

I am very interested in participating. Thanks for the interest,
Francois, we need more people like you who want to use py.log in their
projects :-)

Grig