I’m running the Meltdown Mitigation Python exercise and when I use if-elif-else statements I get warnings from Pylint
For example if my function is:
def reactor_efficiency(voltage, current, theoretical_max_power):
if percentage >= 80:
return 'green'
elif percentage >= 60:
return 'orange'
elif percentage >= 30:
return 'red'
else:
return 'black'
Or if I only include one elif:
def fail_safe(temperature, neutrons_produced_per_second, threshold):
if temperature * neutrons_produced_per_second < 0.90 * threshold:
return 'LOW'
elif 0.90 * threshold <= temperature * neutrons_produced_per_second <= 1.10 * threshold:
return 'NORMAL'
else:
return 'DANGER'
Looking at the latest Pylint docs for R1705, it appears they encourage to use multiple if statements. I guess this is because I’m returning from within the condintional statement rather than setting a variable and returning the variable at the end for example:
def reactor_efficiency(voltage, current, theoretical_max_power):
color = ''
if percentage >= 80:
color = 'green'
elif percentage >= 60:
color = 'orange'
elif percentage >= 30:
color = 'red'
else:
color = 'black'
return color
Should the examples during the Instructions be changed to the above format rather than a return in the if statement?
Hi @gdi0110 
Welcome to the Exercism forums! Thanks for bringing up this issue.
maybe. Or perhaps a second example that shows that strategy. I’ll think on it a bit.
The thing is, R rules in PyLint are for refactoring – they are not syntax errors or warnings, but are intended to point out areas where you should ask if what you’ve done accurately conveys your intent; or otherwise avoids future bugs or issues. There’s not always a hard and fast rule, so they’re better when you discuss them with a mentor or collaborator.
This Stack Overflow Post covers a lot of considerations around this conditionals scenario.
The TL;DR? If you use a return in a series of if-elif-else, it becomes the equivalent of using a series of ifs, but only because using return with a series of ifs mimics the “short-circuit” behavior of an if-elif-else block (which is part of what PyLint is pointing out).
However, some ways of writing that code might be more readable/understandable than others. It depends (on the project, the scenario, the team, future maintenance needs, etc.). Often, explicit is better than implicit … even if PyLint shouts at you. 
All that said, assigning to a variable is the strategy that we use in the exemplar file, and that does take advantage of short-circuiting, so using that as the intro example might be a better way to direct learners.
Again – I will think about it.
1 Like
Alrighty. Decided that assigning to a variable was probably the best “starter strategy”. To that end, I’ve merged this.
It changes the examples across introduction.md files, and adds the “if alternative” + warning + SO post to the about.md file. I’ve also updated the hints file and the exemplar.
LMK if you se anything amiss! .
Thanks for raising the issue, and for the discussion.
1 Like
of course there would be a typo!
Many thanks for the once-over (and the head’s up!) . I’ve corrected it..
maybe. Or perhaps a second example that shows that strategy. I’ll think on it a bit.
of course there would be a typo!