bug-gnulib
[Top][All Lists]
Advanced

[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

Attachment: 0001-gnulib-tool.py-Use-function-arguments-instead-of-mag.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]