Hi Collin,
> Here is the big patch adding type hints. I had a second glance through
> all of the pygnulib/*.py files and believe I got everything.
Looks very good. Applied. Many thanks!
> The typing seems pretty helpful to me already. I am using Emacs eglot
> with pyright which shows many unbound variables + bad function calls
> on objects [1] [2].
It will also help further development: In large pieces of code, it's
easier to understand the existing code and make modifications if there
are type annotations with a decent syntax.
(By "decent syntax" I do *not* mean the K&R C syntax or the Common Lisp
syntax with DECLARE, nor the GNU C attributes syntax:
extern char *dngettext (const char *__domainname, const char *__msgid1,
const char *__msgid2, unsigned long int __n)
__THROW __attribute_format_arg__ (2) __attribute_format_arg__ (3);
)
Still, three remarks:
* In GLConfig.py, it is pointless to enumerate all the possible value
types:
str | float | int | bool | classes.CopyAction | list[str] | None
You could just as well use Any (or any), I guess?
* In GLModuleSystem.py lines 784, 821:
A condition can be a string or True. But
str | bool
makes it look like False was also a valid value. Is possible to
write
str | True
in some way?
* GLFileSystem.py:166
def __init__(self, config: GLConfig, transformers: dict = dict()):
Is it possible to specify the key and value types of the last argument?
> Since that requires all files need the __future__ import, I've removed
> this comment from GLEmiter.py:
>
> # Allow the use of union type specifiers, using the syntax Type1 | Type2,
> # in Python ≥ 3.7. Cf.
> <https://docs.python.org/3/library/__future__.html>
> # and <https://stackoverflow.com/questions/73879925/>.
>
> And added a modified version to main.py under the rest of the rest of
> the coding standards.
Perfect.
Bruno
