[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnulib-tool.py: Fix some unbound variables.
From: |
Collin Funk |
Subject: |
Re: gnulib-tool.py: Fix some unbound variables. |
Date: |
Wed, 10 Apr 2024 08:41:18 -0700 |
User-agent: |
Mozilla Thunderbird |
On 4/10/24 7:17 AM, Bruno Haible wrote:
> 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!
Yes, I tried to add it but was confused since:
>>> print(type(lambda x: True).__name__)
function
But 'is function' does not work.
> The previous knowledge summarization engine told me how to write it:
> callable(module_filter)
Ah, it was correct this time. I guess that makes sense because you can
create classes with the '__call__' method. Then use objects in a
similar way to functions.
> 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.
Yeah, now that I think about it the lambda's are fine. That way we
don't have to deal with importing those across multiple files.
> 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.
True. Sometimes I forget about those and use -Wall + -Wextra and get
greeted with the unused variable/function spam.
I attached the patch with the callable(module_filter) check.
Collin
0001-gnulib-tool.py-Use-function-arguments-instead-of-mag.patch
Description: Text Data