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_libtool, disable_gettext,
> replace_auxdir, ' ')
>
> It seems that the unbound variable will evaluate to 'False', which
> would explain why it still works. Still not good practice. :)
No. If a variable is really unbound at runtime, Python would signal an error.
> This patch silences the warning by initializing solution to False at
> the start of each loop. Easy fix.
The patch misses the point. Let's look at the first hunk in your patch:
for module in modules:
if verifier == 0:
solution = True
elif verifier == 1:
solution = module.isNonTests()
elif verifier == 2:
solution = module.isTests()
if solution:
emit += self.autoconfSnippet(module, toplevel,
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)
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.
Bruno
