Use Python versioning in `msgfmt.py`/`pygettext.py`

[StanFromIreland]

pygettexts/msgfmts versioning system is currently not useful.

cpython/Tools/i18n/pygettext.py

Line 155 in fac41f5

__version__ = '1.5'

cpython/Tools/i18n/msgfmt.py

Line 37 in fac41f5

__version__ = "1.2"

It has not been updated with changes and is of little informational value.

We have three options,

1. Leave it as it is
2. Remove it
3. Replace/Update it to make it useful

1 = nothing changes.

2 Removing it completely would be misleading since pot files without "Generated-By: XXX" in the header are assumed to be generated by xgettext, so we would have to keep "Generated-By: pygettext".

I propose to do 3, as the version number can be useful, since files generated by different versions of the scripts can vary. For reference python-babel does this with their up-to-date version no. To do this I propose to use CPython versioning to make it easier, both for us and for users. This will avoid discussions down the line as to when should we bump the version, and it will make it easier for users to fetch the desired version, i.e. branch 3.15 for pygettext 3.15 and so on.

cc @tomasr8

Linked PRs

• gh-133319: Use python versioning in msgfmt & pygettext #134205

[sobolevn]

Is there anything wrong with the current version? Why do we need to change this? What if someone depends on the version number of gettext is some way?

[StanFromIreland]

Is there anything wrong with the current version?

Not necessarily, but currently it is meaningless. A version number that was last updated 23 years ago does not serve much purpose, it is not helpful in differentiating the actual version of the tool.

Why do we need to change this?

It makes it useful, it actually informs the user about what version was used to generate it.

What if someone depends on the version number of [py]gettext is some way?

[Note: this issue is about the tools pygettext.py/msgmt.py and not Lib/gettext.py]

I do not see any realistic scenario where there would be a dependency on a version number, reiterating my previous points, it is useless in telling the version.

[tomasr8]

(answering mainly for pygettext)

I think if we agree that we want to have a version number, it should be informative. pygettext has not been significantly touched in a long time up until recently so the current version number was somewhat accurate, but in 3.14 there will be lots of bug fixes and overall improvements. Keeping the same version seems rather unhelpful to anyone that might care about it.

At the same time, we don't want to keep a versioning scheme separate from the Python version since pygettext (and msgfmt) are distributed with it, so there would be no meaningful distinction.

Alternatively we could remove the version altogether but that puts the burden on the user to keep track of which python version was used to generate the POT file.

[encukou]

in 3.14 there will be lots of bug fixes and overall improvements.

So, should the version be 3.14 until there's a similar 3.15-only fix?

Should the fixes be in What's New, so users can read about the meaning behind the numbers?

[StanFromIreland]

So, should the version be 3.14 until there's a similar 3.15-only fix?

It is introduced in 3.15 so let's leave it at 3.15, to prevent further confusion in the future since it is not backported.

Should the fixes be in What's New, so users can read about the meaning behind the numbers?

The scripts are not in the stdlib (yet) though they will hopefully move under gettext at some point. From my understanding that would exclude them from Whats New though I am not against it.

[encukou]

I think we need to take a step back.

Alternatively we could remove the version altogether but that puts the burden on the user to keep track of which python version was used to generate the POT file.

Why would they track that?
If they need the Python version, the proposed change doesn't give it to them.
If they need a release number they can match against a changelog to see if it has some improvement or fix, the proposed change doesn't give it to them.

What problem is this solving that can't be solved by removing the version number, or even keeping it as it is?

[StanFromIreland]

Why would they track that?

Users might track it because po files generated by different script versions can vary, especially now as new features are added.

If they need the Python version, the proposed change doesn't give it to them.

I don't know of any reasons, I guess for gettext compatibility, but maybe that's just overkill?

If they need a release number they can match against a changelog to see if it has some improvement or fix, the proposed change doesn't give it to them.

Yes, but I would say that is beyond the scope of this issue, it is the same for the current version number. (Idea: We could keep a separate changelog.txt or something like that. Are there other /tools that have a way to manage this?)

What problem is this solving that can't be solved by removing the version number, or even keeping it as it is?

IMO we still need some way of tracing what version was used to generate the file, removing the version number would not be of much benefit, then again it itself is not very information since it has not been updated when changes were made.

[tomasr8]

Should the fixes be in What's New, so users can read about the meaning behind the numbers?

IIRC, most if not all of the fixes are in the changelog already :)

What problem is this solving that can't be solved by removing the version number, or even keeping it as it is?

I'm not sure whether we should keep a version or remove it altogether but as a user, if a version number is provided, I'd expect it to be useful and something I can rely on.

However, starting from 3.14, the current version number will become quite misleading as there were many changes to pygettext during that time.

Perhaps deprecating and removing the version number altogether is ok. The only issue I see is the fact that for pygettext, we write the version number into the PO file. But I haven't come across any examples in practice where a consumer cares about what tool and version generated the PO file.

@serhiy-storchaka what is your preference?

[serhiy-storchaka]

If it was a part of the stdlib, I would say that we should use the running Python version. But since it is in the Tools directory, there is a chance to run these scripts by different Python. Maybe we can ignore this case, I don't know.