Re: gnulib-tool.py: Fix some unbound variables.

[Bruno Haible]

Hi Collin,

> > A better fix would be revisit this 'verifier'. Either an enum with 3 
> > possible
> > values, or (better) a function  GLModule -> bool. And call it 'moduleFilter'
> > rather than 'verifier'.
> 
> How does this patch look?

Pretty good. The only thing that's missing is the type check for module_filter.
Is it
  module_filter is function                            Nope!
  module_filter is Callable                            Nope!
  module_filter is callable                            Nope!
The previous knowledge summarization engine told me how to write it:
  callable(module_filter)

> The conditionals
> can be refactored to remove a level of nesting in a few places. I
> didn't do that now since it would make the patch harder to follow.

It's OK like this. Similar enough to gnulib-tool.sh.

> I've just used lambda functions since these functions are just
> wrappers around GLModule methods. I'm not sure if it is better to
> define them in GLModuleSystem.py or something. Since you are the
> lisp expert, I will trust your judgment here.

What I considered is write 3 constants:
  ALL_MODULES_FILTER = lambda module: True
  NON_TESTS_MODULES_FILTER = lambda module: module.isNonTests()
  TESTS_MODULES_FILTER = lambda module: module.isTests()
but that's probably not worth it either.

> Also, now I see an annoying warning:
> 
>       lambda module: True  # warning under 'module'
> 
> because pyright thinks it is unused [2].

This is a problem with gcc's warnings as well. Such tools don't make
the distinction between a function that is only meant to be called
directly and a function which needs to adhere to a certain signature.

You can open a bug report with that tool (with a trimmed-down test case);
then it might get fixed in a year or two.

Bruno