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

[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 analysis of your IDE, which
> does not realize that the 'verifier' variable has only values 0, 1, 2 —
> despite of the validation in the same function:
> 
>         if type(verifier) is not int:
>             raise TypeError('verifier must be an int, not %s'
>                             % type(verifier).__name__)
>         if not (0 <= verifier <= 2):
>             raise ValueError('verifier must be 0, 1 or 2, not %d' % verifier)

Ah, okay thanks for the explanation. I think I understand what is
going on now. So the unbound variable only exists if verifier is not
0, 1, or 2. In that case we would get a NameError since solution does
not get defined. To combat this we have that input check at the start
of the function. This was just a problem with my IDE and I failing to
notice that check...

> 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'.
> 
> When this is done, there will be no 'if' statement with missing 'else' case,
> and I bet your IDE's warning will go away.

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...

Collin