Re: gnulib-tool.py: Stop using codecs.open

[Collin Funk]

Hi Bruno,

On 4/13/24 4:08 AM, Bruno Haible wrote:
> It seems that codecs.open is frowned upon, nowadays [1],
> and that the Python 3 way of opening a file is a built-in function 'open' [2].

Thanks for this patch. When I started working on gnulib-tool.py I
didn't even know the codecs module existed, since I had never used
Python 2.

> Let's use this consistently. With newline='\n' in order to match what
> gnulib-tool.sh does.

Sounds good. You mentioned removing the constants.nlconvert() stuff in
an earlier email [1]. How about these two patches?

Patch 0001 removes nlconvert and all of its calls. That should make
sure gnulib-tool.py and gnulib-tool.sh deal with newlines the same
way.

Patch 0002 removes the 'NL' constant. I assume this was to match
gnulib-tool.sh's use of "$nl"? But there it is used to expand to a
newline character without breaking lines right? For example, this:

     func_append license_incompatibilities "$module $license$nl"

vs. this:

     func_append license_incompatibilities "$module $license
"

Since we use a mix of '\n' and constants.NL, I would just like to use
'\n' everwhere consistently.

> Specifying encoding='utf-8' is what makes the most sense today. If a package
> still has a configure.ac or Makefile.am in ISO-8859-1 encoding, this will
> probably fail. Let's see if people report a problem with this; it should be
> very rare.

Sounds good.

[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00370.html

Collin

0001-gnulib-tool.py-Don-t-perform-newline-conversions.patch
Description: Text Data

0002-gnulib-tool.py-Write-newlines-consistently.patch
Description: Text Data