[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] gnulib-tool.py: Improve output of testdir Makefile.am.
From: |
Collin Funk |
Subject: |
Re: [PATCH] gnulib-tool.py: Improve output of testdir Makefile.am. |
Date: |
Wed, 21 Feb 2024 17:43:59 -0800 |
User-agent: |
Mozilla Thunderbird |
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