On 5/4/24 8:17 AM, Bruno Haible wrote:
>> For CI, I am thinking it is best to ignore the typing warnings for the
>> time being. Since gnulib-tool.py needs a bit more refactoring for that
>> to be helpful. It was written before typing was a thing. :)
> 
> Hmm. Is that refactoring, that you are imagining, intrusive? If it's
> intrusive, then maybe we should leave it alone. You already introduced
> types in the function signatures and in the fields of classes; what else
> is missing?

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.

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.

>> I'm not too familiar with the GitLab CI stuff. Would a Makefile in
>> gnulib/pygnulib with some checks work?
> 
> Yes, a Makefile in pygnulib/ would be sufficient. The top-level Makefile then
> may invoke it.

Sounds good. I'll have a look at getting started with something in a bit.

[1] 
https://mypy.readthedocs.io/en/stable/type_narrowing.html#type-narrowing-expressions

Collin

Reply via email to