Re: gnulib-tool.py: Add a new GLFileTable class.

[Bruno Haible]

Collin Funk wrote:
> for instance variables I
> rather put them outside __init__. It also serves as a decent place to
> add comments that don't belong in doc strings.

Yes. For instance variables that are used in several methods it would seem
odd to declare them in __init__. To me, __init__ is the place where they
are initialized, not declared.

Bruno

Re: gnulib-tool.py: Add a new GLFileTable class.

[Collin Funk]

On 4/25/24 1:11 AM, Bruno Haible wrote:
> Interesting syntax. This makes the class easier to understand. You're welcome
> to do the same thing with the other classes (except for GLError.message, which
> is private to a single method).

I agree. I originally wanted to add it to GLModuleTable when I was
looking at it previously. I imagine that section of code is probably
the most difficult for someone new to understand compared to the rest
of gnulib-tool.py.

Before I made the changes to GLModule.__hash__ the types were
something like this:

self.dependers: dict[str, list[str]] # 'module-name' : ['dep1', 'dep2']
self.conditionals: dict[str, str | bool] # key is 'module1---module2'

Which doesn't really tell us much without looking more into the class.
After my changes to GLModule.__hash__ it is a bit better:

self.dependers: defaultdict[GLModule, set[GLModule]]
self.conditionals: dict[tuple[GLModule, GLModule], str | bool]

This syntax can also be used on assignments in __init__ or for normal
variables like this:

# type hinted 'self.dependers = []'.
self.dependers: defaultdict[GLModule, set[GLModule]] = []

Which helps mypy and other type checkers who cannot infer the type
otherwise. I felt it was a bit cluttered so for instance variables I
rather put them outside __init__. It also serves as a decent place to
add comments that don't belong in doc strings.

I'll probably add them once I get around to making variables private
as we discussed previously.

> We are not going to lower the version dependency:
>   - No one asked for it in the beta testing process since last week.
>   - Python 3.6 (and even 3.7) is already end-of-life [1].

Sounds good. In any case it is always good to double check quickly
before modernizing like this. I run all the tests with Python 3.7
before submitting patches for the same reason.

Collin

Re: gnulib-tool.py: Add a new GLFileTable class.

[Bruno Haible]

Collin Funk wrote:
> I've applied the following patch adding a GLFileTable class as
> discussed here:
> 
> https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00357.html

Thanks! Looks good.

> +class GLFileTable:
> +'''The GLFileTable class stores file information for the duration of the
> +operation being executed.'''
> +
> +all_files: list[str]
> +old_files: list[tuple[str, str]]
> +new_files: list[tuple[str, str]]
> +added_files: list[str]
> +removed_files: list[str]

Interesting syntax. This makes the class easier to understand. You're welcome
to do the same thing with the other classes (except for GLError.message, which
is private to a single method).

> This syntax was introduced in Python 3.6 which is okay for our
> dependency on Python 3.7. For older versions they can be removed or be
> placed in comments [1]. I've gone with it since I imagine there will
> be bigger fish to fry by lowering the version dependency.

We are not going to lower the version dependency:
  - No one asked for it in the beta testing process since last week.
  - Python 3.6 (and even 3.7) is already end-of-life [1].

Bruno

[1] https://en.wikipedia.org/wiki/History_of_Python#Table_of_versions