[GRASS-dev] [GRASS GIS] #2425: Import translation function instead of using a buildin
GRASS GIS
trac at osgeo.org
Wed Sep 17 16:34:50 PDT 2014
#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>
More information about the grass-dev
mailing list