[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 wenzeslaus):

 Replying to [comment:1 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.
 >

 This is certainly an issue. Python `logging` module could help in
 implementing the functionality but it is still necessary to implement
 GRASS interface (the environmental variable, etc.).

 It seems to me that better option is to use `G_message()` etc through
 `ctypes`. There is always some complexity in using `ctypes` but we need
 them work anyway for many things (some scripts, pygrass, parts of GUI), so
 making them necessary for all scripts is not such an issue from my point
 of view.

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

 Although, this approach might be beneficial at more places in GRASS
 (mainly GUI-related things (`g.message` is actually GUI thing too)) and I
 would like to have a nice way how to do it when necessary, I don't think
 that it is better than `ctypes`. It think `ctypes` is a better option.

 I think that it is fragile as well as `ctypes`. The difference, I can see,
 is the number of created processes. When we speak about call of one Python
 module there is no such a difference. One `g.message` server process
 versus zero when using `ctypes`. But when we speak about calling Python
 module many times (> 100), we have now a lot of `g.message` server
 processes versus zero in case of `ctypes`.

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