aryansk · 2026-08-24T17:14:50Z

Problem

Tools/i18n/pygettext.py diverges from GNU xgettext in two empty-input cases:

No input file given — xgettext prints xgettext: no input file given and Try 'xgettext --help' … with exit 1. pygettext silently generated an empty messages.pot with only a header.
No messages to extract — xgettext produces no output when no strings are found. pygettext still wrote a header-only messages.pot.

Issue #133049 reports both; tomasr8 confirmed the first is clear and should be fixed (input file should be required), while the second is debated but the issue requests xgettext-compatible behavior.

Change

In Tools/i18n/pygettext.py:main() — after expanding args via getFilesForName, check if not args: → usage(1, "pygettext: no input file given\nTry 'pygettext --help' for more information.")
After visiting files, check if not visitor.messages: → verbose message to stderr and sys.exit(0) without creating/writing the output file (covers both -o FILE and - stdout cases). This matches xgettext's "no output is generated if there are no messages".

Keep unrelated cleanup out of this PR.

Why this approach

Minimal, xgettext-compatible, and respects the maintainer's lean: the first fix is uncontroversial and matches the exact xgettext error wording; the second implements the requested "no empty output" while remaining silent unless -v is given, so existing workflows that expect an empty POT can be detected via the exit and verbose hint.

Testing

command: python3.14 Tools/i18n/pygettext.py (no args)
result: prints __doc__ + "pygettext: no input file given\nTry 'pygettext --help' …" to stderr, exit 1 — matches xgettext

command: echo 'print("hello")' > /tmp/test.py && python3.14 Tools/i18n/pygettext.py -o /tmp/out.pot /tmp/test.py; ls /tmp/out.pot
result: no 
8000
out.pot created, exit 0

command: echo '_("hello")' > /tmp/test2.py && python3.14 Tools/i18n/pygettext.py -o /tmp/out2.pot /tmp/test2.py; cat /tmp/out2.pot
result: header + msgid "hello" written correctly

command: python3.14 -m py_compile Tools/i18n/pygettext.py
result: ok (3.13/3.14; 3.9 fails on unrelated PEP 701 f-string syntax already on main)

command: git diff --check
result: clean

make check for pygettext is covered by test.test_tools.test_i18n (skipped in this env due to missing build dir, but git diff --check and manual checks pass).

Documentation and release impact

User-facing behavior updated (CLI error / empty-output)
Changelog/release note needed: bug fix, no docs
Migration or compatibility note needed
No documentation impact

Review notes

Known limitations: verbose-only hint for empty-messages case
Follow-up issue, if any: none
Security/licensing considerations: none

Issue: pygettext generates output even when there should be none #133049

…sages Fixes python#133049 pygettext now matches GNU xgettext behavior: * No input file given → error "pygettext: no input file given" and "Try 'pygettext --help' ..." with exit 1, instead of silently generating an empty messages.pot. * No strings to extract → no output file generated (exit 0, verbose message to stderr), instead of writing a header-only messages.pot. This matches xgettext which produces no output when there are no messages. Validation: manual check with python3.14 Tools/i18n/pygettext.py (no args → exit 1 with error, empty file → no out.pot, file with _() → out.pot with header+msgid); py_compile passes on 3.13/3.14.

python-cla-bot · 2026-08-24T17:14:54Z

All commit authors signed the Contributor License Agreement.

bedevere-app · 2026-08-24T17:14:54Z

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

bedevere-app Bot mentioned this pull request Aug 24, 2026

pygettext generates output even when there should be none #133049

Open

Navigation Menu

Uh oh!

Uh oh 8000 !

gh-133049: make pygettext match xgettext for empty input/no messages - #156322