Re: [Gnumed-devel] review of possible checkin.

[Karsten Hilbert]

> it's easier to use print statements, and then disable them with # after
> debugging the module :
> the reason is that the log becomes so full, it's difficult to discern the
> section one is trying to debug. The #print statements can be later
> removed , or changed to logging if there is long term value in keeping
> the debugging statement around.
I agree with Syan here to some extent.

Prints are fine for debugging things before and between
checkins. However, once debugging is "over" - eg the coder
decides, well, it's good enough for now - then the prints
should be removed (yes, we all forget some). However, there
will still be errors occurring during "deployment". Those
shoudl be logged to the log along with infos, notices, etc
etc.

>  Yes there are log levels, and possibly filtering of logging based on 
> originating module, but I haven't worked out how to do that at the 
> configuration level ,environment level or  the command line level ( is 
> it documented?).
We don't have formal module level filtering. The documentation
is in gmLog.py.

> The howto should be more concrete than just guidelines, "one should use
> LogException() because it prints out a stacktrace in the log where the path
> to an exception can be traced through line numbers in each module file."
> 
> Is anyone using a tool/editor that can link a log files  path  
> statements to  a
> editor to auto-open the module file concerned at the line number?
> (maybe one should be written).
Emacs does that (and I'm sure any number of Python IDEs) as
long as the original stack trace output is provided on stderr.
I tried to take care to do that as Ian once requested it being
done.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346