[GRASS-dev] [GRASS GIS] #2425: Import translation function instead of using a buildin

[GRASS GIS]

#2425: Import translation function instead of using a buildin
-----------------------------------------------------+----------------------
 Reporter:  wenzeslaus                               |       Owner:  grass-dev@…              
     Type:  task                                     |      Status:  new                      
 Priority:  normal                                   |   Milestone:  7.1.0                    
Component:  Translations                             |     Version:  svn-releasebranch70      
 Keywords:  python, underscore, _, gettext, doctest  |    Platform:  All                      
      Cpu:  Unspecified                              |  
-----------------------------------------------------+----------------------

Comment(by glynn):

 Replying to [comment:2 wenzeslaus]:

 > That's a good point but both doctest and gettext are part of Python and
 they are still not compatible. I would say that they don't want to change
 it. The issue is known for a long time and by a lot of people:

 In which case, I would say that doctest loses. Either come up with a
 workaround for doctest, or live without it. It isn't acceptable to require
 every programmer to jump through hoops for the sake of doctest.

 > The other motivation is that wxGUI needed some change (since the former
 state was not working) and the only two solutions we found were putting
 `install` call to each file (which is agiast buildin and gettext
 documentation) or using explicit imports.

 I believe that wxPython has its own "_" related to its own I18N subsystem.
 If possible, I would prefer to "fix" wxPython. And if that isn't possible,
 I would prefer that any sub-optimal solutions don't end up infecting non-
 wxGUI code.

 > I think we should you the same practice everywhere but what remained me
 about this issue was that I have seen in some Python editor an error
 message which was saying that `_(...)` does not take any arguments (or
 something like that, I was not able to get or reproduce the message). This
 is the kind of message is the same as given by doctest, so I guess
 explicit imports would solve both issues.

 This sounds like the interactive shell using "_" as a variable to hold the
 result of the last expression:
 {{{
 > 2 + 3
 5
 > _
 5
 > __builtins__._
 5
 }}}

 It may be that doctest is also using "_" in this way in order to
 faithfully mimic the behaviour of the interactive shell. Actually, there's
 no "may" about it; the behaviour is implemented by
 [https://docs.python.org/2.7/library/sys.html#sys.displayhook
 sys.displayhook]:
 {{{
 sys.displayhook(value)

     If value is not None, this function prints it to sys.stdout, and saves
 it in __builtin__._.

     sys.displayhook is called on the result of evaluating an expression
 entered in an interactive Python session. The display of these values can
 be customized by assigning another one-argument function to
 sys.displayhook.
 }}}

 doctest.py explicitly restores this function to its initial value (from
 [https://docs.python.org/2.7/library/sys.html#sys.__displayhook__
 sys.__displayhook__]) while executing the tests:
 {{{
         # Make sure sys.displayhook just prints the value to stdout
         save_displayhook = sys.displayhook
         sys.displayhook = sys.__displayhook__
 }}}

 Indeed, trying to debug code which uses _() by pasting it into an
 interactive session often fails because the shell assigns `__builtins__._`
 every time you enter a statement. But that's just how it is; the function
 has to be called _() so that xgettext can identify strings for
 translation.

 One possibility is to replace both sys.displayhook and
 `sys.__displayhook__` with something which preserves `__builtin__._` while
 running doctest. Obviously, any examples which rely upon the interpreter
 setting "_" won't work, but that's easy enough to avoid (and in any case,
 they won't work if the code use "from whatever import _", because
 variables in the current module override built-ins).

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