Hi Collin, > I am hesitant to change the TODO file until we can better testing > everything.
My main test case is as written at the top of gnulib-tool.py.TODO: A particular checkout of wget2, with a particular gnulib-tool invocation. Make 20 or 50 copies of this directory; then run each gnulib-tool.py with and without some modifications, on two different copies, then "diff -r -u", and you'll see the effect of the modifications. Collin Funk wrote: > This patch should (hopefully) fix the following commit entries: > > 16c3e1868a15a5946c0f0f7df6e107e9b3c6389d > d465dd70e1ec5fe332160780eb66511028f5897b > 39d08c09b444db57f45804bfe86ee17203c45a8a > 3a24ff8a1045d8d38824088c0984bb59d0192e65 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?). > Also, is there a preference against using f-strings [1] or is it just > because the code is old? I find them to be much more readable than the > older syntax for formatting. > > [1] https://docs.python.org/3/tutorial/inputoutput.html#tut-f-strings 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. Bruno [1] https://peps.python.org/pep-0498/ [2] https://repology.org/project/python/versions
