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

2024-04-10 Thread Bruno Haible
Collin Funk wrote: > I attached the patch with the callable(module_filter) check. Thanks! Applied. This eliminates one more item from the TODO list. Bruno

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

2024-04-10 Thread Collin Funk
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 functionNope! > module_filter is CallableNope! > module_filter is callable

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

2024-04-10 Thread 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 chec

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

2024-04-10 Thread Collin Funk
Hi Bruno, On 4/9/24 12:04 PM, Bruno Haible wrote: > 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? This method seems much clearer to m

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

2024-04-09 Thread Collin Funk
On 4/9/24 1:06 PM, Eric Blake wrote: > It does, since callable objects exist as first class citizens. For > example: Ah, I see. Thanks for the examples. Collin

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

2024-04-09 Thread Eric Blake
On Tue, Apr 09, 2024 at 12:35:27PM -0700, Collin Funk wrote: > Yes, I see what you mean. I very much prefer the 'moduleFilter' idea. > It would allow us to remove a lot of the repetitive conditionals. Now > I just have to figure out how to do that. If only Python had function > pointers... It does

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

2024-04-09 Thread Collin Funk
On 4/9/24 12:04 PM, Bruno Haible wrote: > According to > https://stackoverflow.com/questions/2829528/whats-the-scope-of-a-variable-initialized-in-an-if-statement > it is perfectly OK to initialize a variable 'solution' in various 'if' > branches. > > The warning apparently comes from the data flow

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

2024-04-09 Thread Bruno Haible
Hi Collin, > In GLEmiter.autoconfSnippets I see many warnings that a 'solution' > variable may be unbound when it is used. > > if solution: # Solution may be unbound here. > emit += self.autoconfSnippet(module, toplevel, > disable_l

gnulib-tool.py: Fix some unbound variables.

2024-04-09 Thread Collin Funk
ch loop. Easy fix. CollinFrom 742d2367663fb70940d9e7b7ae47d3fed2c83d5e Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Tue, 9 Apr 2024 10:47:23 -0700 Subject: [PATCH] gnulib-tool.py: Fix some unbound variables. * pygnulib/GLEmiter.py (GLEmiter.autoconfSnippets): Declare the solution flag and set it to False at the star