Re: gnulib-tool.py: Fix an undefined function name.

[Bruno Haible]

Hi Collin,

> > Hmm. Is that refactoring, that you are imagining, intrusive? ...
> 
> Depends on the specific warning being addressed. :)
> 
> There are more trivial cases like GLMakeFileTable which stores
> information as a dictionary. We have a table of makefile variables:
> 
>      table: list[dict[str, str | bool]]
>      # Each 'dict' has the following 'key': type.
>      { 'dir': str, 'var': str, 'dotfirst': bool }
> 
> Using a value from a key at this will lead to a type error unless you
> "narrow" the union [1]:
> 
>    if type(makefiletable['dir']) is str:
>       makefiletable.split('/') # Would not work on 'bool'.
> 
> Me and you can tell the use of makefiletable['dir'] will return a str,
> but the type checker can't. Using a class like this:
> 
>     class GLMakeVar:
>         dir: str
>         var: str
>         dotfirst: bool
> 
> Would be type-checkable and would probably be easier for new
> contributors to understand, in my opinion.

I agree. OK for this refactoring.

> Other cases are less trivial and bring up situations which may cause
> errors. For example there are many warnings about "list[GLModule]"
> actually being "list[GLModule | None]".
> 
> This is caused by functions like GLModule.getDependenciesWithoutConditions():
> 
>      def getDependenciesWithoutConditions(self) -> list[GLModule | None]:
>          # Read the "Depends-on" and find each module name.
>          # Run self.modulesystem.find() to get the GLModule objects.
>          # Return the list of dependencies.
> 
> Remember that modulesystem.find() returns None with a warning (or
> error depending on arguments) if the module cannot be found. Therefore,
> this function should probably filter out None in the return value.

Right. It makes no sense for the returned list to contain None values.

Bruno