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
