On 2/21/24 4:10 PM, Bruno Haible wrote: > I'm a bit unhappy with this way of working. Your patches surely > go into the right direction, but I would prefer to receive them > 1) one by one, > 2) with the corresponding gnulib-tool.py.TODO entry removal. > Because if we don't keep track of which entries are still left, it > opens the door to confusion (was a patch applied? was it applied > but not tested? was only a partial translation of the commit to > python achieved?).
I was having similar thoughts while writing the ChangeLog entry. Your method sounds much better. I'll rewrite them and submit each patch individually even if the change is a single line. Should I mention the commit being removed from the gnulib-tool.py.TODO file in the ChangeLog and commit message? I think it might help tracking down any issues that might come up later. > It looks like the f-strings were introduced in Python 3.6 [1], and > Python 3.6 or newer is available on the vast majority of distros [2]. > So, there is no technical reason not to use f-strings. And it appears > to have become mainstream style of Python coding. So, please go ahead > and use f-strings in new code, if you want. > > We _may_ also refactor the existing code to use f-strings later, when > the Python rewrite is complete. But now is not the right moment for > that. Sounds good. I think I will just try to match surrounding code for now. Python 3.8 is the lowest version still supported [1]. I'll reference documents from that version when making changes. Older versions will probably still work but it is nice to have a point of reference. [1] https://devguide.python.org/versions/ Thanks for the advice, Collin
