[GRASS-dev] [GRASS GIS] #2127: Python implementation of g.message

[GRASS GIS]

#2127: Python implementation of g.message
-------------------------+--------------------------------------------------
 Reporter:  huhabla      |       Owner:  grass-dev@…              
     Type:  enhancement  |      Status:  new                      
 Priority:  normal       |   Milestone:  7.0.0                    
Component:  Python       |     Version:  svn-trunk                
 Keywords:               |    Platform:  Unspecified              
      Cpu:  All          |  
-------------------------+--------------------------------------------------

Comment(by glynn):

 Replying to [ticket:2127 huhabla]:

 > In case these messages are called many times (> 100), the overhead of
 calling g.message rises and can slow the actual processing massively down.

 Why would you call them so many times?

 I can just about understand it for debug(), in which case it might be
 better to use native Python equivalents (e.g. the `logging` module). If
 you're calling anything else >100 times (even verbose()), the script is
 probably too chatty.

 > I would suggest to implement the behavior of g.message directly in
 Python to reduce the overhead, replacing the functions that make use of
 g.message:

 Then we would need to keep the two in sync.

 G_message() etc aren't exactly trivial; they support multiple output
 formats, word-wrapping, configution of verbosity and output format via
 environment variables and command-line switches, and reporting of messages
 via stderr, log file and/or email.

 If performance is a genuine issue, I would rather see g.message enhanced
 so that it can be used as a server, with the script spawning a single
 persistent g.message process which can accept multiple messages (of
 varying priorities) read from stdin.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2127#comment:1>
GRASS GIS <http://grass.osgeo.org>