#3790: Cleanup gettext usage for python code
--------------------------+-------------------------
Reporter: pmav99 | Owner: grass-dev@…
Type: enhancement | Status: reopened
Priority: normal | Milestone: 7.8.0
Component: Python | Version: svn-trunk
Resolution: | Keywords:
CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------
Comment (by wenzeslaus):
Replying to [comment:5 pmav99]:
> Disclaimer: The real goal of this refactoring was to get rid of
{{{os.getenv("GISBASE")}}} calls at the module level from all over the
place. This is a prerequisite for #3772. The scripts and the GUI code
didn't really need to be touched, but I did them too for uniformity.
You will have to help me here. Why is the relative path solution from
#3772 not applicable to the explicit import approach?
In relation to that, since #3772 is about using `grass` as a standard
Python package, I think it should follow the "Helman's advice" for a
Python package.
> Replying to [comment:4 wenzeslaus]:
> > The things in lib/python are potentially (and actually) used as Python
modules by other applications or scripts. Thus from
https://pymotw.com/2/gettext/index.html#module-localization, it is
actually the second option which applies:
> >
> > > //For a library, or individual module, modifying `__builtins__` is
not a good idea because you don’t know what conflicts you might introduce
with an application global value. You can import or re-bind the names of
translation functions by hand at the top of your module.//
>
> ...
>
> I am not sure that GRASS was actually following Doug Helman's advice.
More specifically, almost all GRASS modules used to import the {{{grass}}}
library before actually calling {{{gettext.install()}}} on their own
([https://github.com/GRASS-GIS/grass-
ci/pull/9/commits/0983ca068d6f7363d2fede26f77b8aed76c87bcc source]). ...
Anyway, the end result is that most of the time, if not always, as soon as
you imported the {{{grass}}} lib, the {{{builtins}}} were modified anyway.
Please read #1739 and #2425 linked from there. I explain that the wxGUI is
using the practice while the library (lib/python) is not and it should.
> That being said, I am completely open to any improvements. I am also
perfectly fine with following Mr. Helman's advice (i.e. by adding explicit
imports in each and every {{{grass}}} lib module) if someone wants to
contribute that. But IMHV the proposed implementation is cleaner than the
previous one.
Cleaner in which way? I think the registration of the domains separately
and all at once is a separate issue from "Helman's advice" (which is
notably also the way which Django is following).
> > So far we were relatively successful in keeping the GUI separate
(whether for performance or code organization reasons).
>
> I don't really see any coupling of the GUI code with the {{{grass}}}
library. All the {{{grass}}} library does is registering the "grasswxpy"
domain. It doesn't import anything.
It is not just the imports. The idea is that you should be able to install
GRASS GIS as command line only application without any GUI parts. But
there is more than one way to deal with this. If the registration of the
domain can just fail silently, that's probably good enough in this
particular case. However, as I said, this is a separate issue.
What is crucial here are the explicit imports versus using builtin. There
were issues with builtin solution in the past (hence #1739), builtin `_`
currently causes issues (doctests, static code linting), builtin solution
is not considered good practice for libraries (Helman, Django) and the
change breaks wxGUI according to #3838. Thus, I suggest reverting it (at
least the builtin part) and finding a different solution for #3772.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3790#comment:10>
GRASS GIS <https://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
