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
