PEP 282: A Logging System -- comments please

[Bengt Richter]

On Sat, 09 Mar 2002 17:17:13 GMT, "Fredrik Lundh" <fredrik at pythonware.com> wrote:

>Edward K. Ream wrote:
>> Dynamic tracing is trivial to implement.  More importantly, it is
>> simpler to use and more flexible than any static scheme such as the one
>> described in 282.
>
>except that in real systems, the end user couldn't care less
>about what/when/how your Python functions are called.
>
>they do care about syslog-compatibility, severity levels, and
>trivial things like getting the same logging messages also after
>you've refactored your program...

Yes, ISTM standardizing the format of log files is of primary importance,
and we should be careful that a convenient mechanism doesn't establish
a de facto format that locks out desirable tool synergy possibilities.
(This has to be an old itch. Is there an RFC? Shall I be lazy and just
ask rhetorically, and not google? Yes, for now ;-)

If you have a standard format it is not hard to filter single-line stuff
for particular concerns even just using grep. If you have a standard for
context-entry/context-exit logging you can use standard tools to extract
the chunks of interest. If you have time tagging standards with extended
options you may be able to glean performance/profiling info in a standard
way. You might want a cheap way to log time tagged sync into all channels.
Etc., etc., and it should be easy to filter the log(s) to drive source browsing.

The point is the log format is more important than how it got written. 

A convenient standard log module will certainly help standardizing. You
could also make it a command line option to instantiate log (and a
devlog alias) as a builtin, for even more convenience.

It might be interesting to give the parser a simple line exclusion capability
(perhaps based on name token match to supplied names). Then you could e.g. run
with devlog statements excluded (including the devlog=log alias-defining statement)
and later strip them out of the source by the same pattern. The exclusion names
could be a command line option also (just an OTTOMH idea). You could in/ex-clude
arbitrary debug functions calls similarly.

It would be nice to be able to distribute log-capable software with logging
optimized out by default, but available. I don't think that a developers'
code line exclusion capability would be suitable for that, though.

IOW, I could see a development version of software being heavily log-enabled
and assert-filled, and it would be convenient to anticipate optimizing it
out optionally during test runs, and probably stripping most of it out for
a final version. If you chose simple conventions for writing log statements
on lines by themselves, and differentiated to-be-stripped development code
from final in some standard way (something to discuss and decide) like using
e.g., a standard devlog.error("this will be stripped") alias for log, you
could make the job relatively easy.

I'd like see a log file grammar definition discussed first, before a nice
convenient log module establishes a premature de facto standard.
I'd like to see a log file grammar be part of the PEP, not just something
to be imperfectly inferred from the examples.

I recognize that the author is researching precedents and putting a lot of
effort into getting it right, but I think discussion focusing on the log
file grammar and various real uses will make future tool synergy more likely.

Tool synergy might be a good topic for a PEP section.

Regards,
Bengt Richter