Idea: msgfmt.py and pygettext..py should be -m executable modules
Currently, the documentation (as well as plenty of other places on the Internet, such as Stack Overflow answers) mentions msgfmt.py and pygettext.py. See https://docs.python.org/3/library/gettext.html
(Python also includes pure-Python versions of these programs, called pygettext.py and msgfmt.py; some Python distributions will install them for you. pygettext.py is similar to xgettext, but only understands Python source code and cannot handle other programming languages such as C or C++. pygettext.py supports a command-line interface similar to xgettext; for details on its use, run pygettext.py --help. msgfmt.py is binary compatible with GNU msgfmt. With these two programs, you may not need the GNU gettext package to internationalize your Python applications.)
The problematic part is: "some Python distributions will install them for you" As a Python distributor, I may ask myself a question: Where do I install those? As a Python user, I may ask: Where did the distributors put them, and did they? So I suggest we make those modules instead and we document how to use them. It might be: $ python3 -m gettext And: $ python3 -m gettext.msgfmt And (provided as a shortcut): $ python3 -m msgfmt I feel that using -m is the general direction Python is going, considering this message: $ pyvenv ... WARNING: the pyenv script is deprecated in favour of `python3.7 -m venv` It also gives the user a choice for Python version on a system with multiple Python versions installed as the user could do: $ python3.6 -m gettext Or $ python3.7 -m gettext While with e.g. /usr/bin/pygettext.py this adds unnecessary burden on the distributor to package /usr/bin/pygettext-3.7.py etc... This idea originates at https://bugzilla.redhat.com/show_bug.cgi?id=1571474 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
On Mon, Jul 23, 2018 at 2:16 PM, Miro Hrončok <mhroncok@redhat.com> wrote:
Currently, the documentation (as well as plenty of other places on the Internet, such as Stack Overflow answers) mentions msgfmt.py and pygettext.py.
See https://docs.python.org/3/library/gettext.html
(Python also includes pure-Python versions of these programs, called pygettext.py and msgfmt.py; some Python distributions will install them for you. pygettext.py is similar to xgettext, but only understands Python source code and cannot handle other programming languages such as C or C++. pygettext.py supports a command-line interface similar to xgettext; for details on its use, run pygettext.py --help. msgfmt.py is binary compatible with GNU msgfmt. With these two programs, you may not need the GNU gettext package to internationalize your Python applications.)
The problematic part is: "some Python distributions will install them for you"
As a Python distributor, I may ask myself a question: Where do I install those?
As a Python user, I may ask: Where did the distributors put them, and did they?
So I suggest we make those modules instead and we document how to use them.
Not completely "instead" perhaps; the original Tools/i18n/*.py scripts can be changed to just import the new module and call it.
It might be:
$ python3 -m gettext
+1
And:
$ python3 -m gettext.msgfmt
+1 Note that this means gettext will need to become a package.
And (provided as a shortcut):
$ python3 -m msgfmt
-1. This would mean adding a new top-level module to the standard library. Let's not pollute that namespace just to provide a shortcut.
I feel that using -m is the general direction Python is going, considering this message:
$ pyvenv ... WARNING: the pyenv script is deprecated in favour of `python3.7 -m venv`
It also gives the user a choice for Python version on a system with multiple Python versions installed as the user could do:
$ python3.6 -m gettext
Or
$ python3.7 -m gettext
While with e.g. /usr/bin/pygettext.py this adds unnecessary burden on the distributor to package /usr/bin/pygettext-3.7.py etc...
Yes – pygettext depends on the Python version, so being able to do this sounds very useful. Less so for msgfmt of course. I'm adding Barry Warsaw, who originally wrote pygettext and AFAIK still does i18n in Python. Barry, does this sound reasonable to you?
On Mon, Jul 30, 2018 at 8:43 AM, Petr Viktorin <encukou@gmail.com> wrote:
On Mon, Jul 23, 2018 at 2:16 PM, Miro Hrončok <mhroncok@redhat.com> wrote:
It might be:
$ python3 -m gettext
+1
And:
$ python3 -m gettext.msgfmt
+1 Note that this means gettext will need to become a package.
And (provided as a shortcut):
$ python3 -m msgfmt
-1. This would mean adding a new top-level module to the standard library. Let's not pollute that namespace just to provide a shortcut.
Speaking of shortcuts, is there a reason that it should be "python -m json.tool" versus "python -m json" (keep the old probably forever, but have the shorter as a synonym)? And as a broader question, is there opposition to generating patches to make packages executable that may be useful as a CLI? Would be nice if the UUID or random modules could directly spit something out, e.g. "python -m uuid -4". Counterargument that you could "python -c "import uuid;print(uuid.uuid4())". Nick
Shortcuts designed for CLI are just to "be more mnemonic" have to be considered with caution. If gettext is a package, it means the whole python community shoud agree on that. msgfmt is part of gettext, so yes, python -m gettest.msgfmt is the best long lasting command. Or it could be 'python -m gettest msgfmt'. If you're using CLI, 90% of chances you know that if you don't like "python -m gettest.msgfmt" because it's too long, you can add a `alias dotrans='python -m gettest.msgfmt'` in your .bashrc so that you can simply write "dotrans Something".
Shortcuts designed for CLI are just to "be more mnemonic" have to be considered with caution. If gettext is a package, it means the whole python community shoud agree on that. msgfmt is part of gettext, so yes, python -m gettest.msgfmt is the best long lasting command. Or it could be 'python -m gettest msgfmt'. If you're using CLI, 90% of chances you know that if you don't like "python -m gettest.msgfmt" because it's too long, you can add a `alias dotrans='python -m gettest.msgfmt'` in your .bashrc so that you can simply write "dotrans Something".
On 7/30/2018 9:43 AM, Petr Viktorin wrote:
On Mon, Jul 23, 2018 at 2:16 PM, Miro Hrončok <mhroncok@redhat.com> wrote:
$ python3 -m gettext.msgfmt
+1 Note that this means gettext will need to become a package.
Once there is a command line interface, arguments can be supplied to the module, as in python -m gettext msgfmt. This only affects the newly added main function. -- Terry Jan Reedy
participants (5)
-
Miro Hrončok -
Nick Timkovich -
Petr Viktorin -
Robert Vanden Eynde -
Terry Reedy