[Tutor] pylint(too-many-nested-blocks)

[Mats Wichmann]

On 11/27/21 20:51, Phil wrote:
> "https://pycodequ.al/docs/pylint-messages/r1702-too-many-nested-blocks.html" 
> describes this error as:
> 
> "Used when a function or method has too many nested blocks. This makes 
> the code less understandable and maintainable."
> 
> The following is one of several functions that fits this description and 
> I'm wondering how I might reduce the number of for-loops. If the number 
> of for-loops cannot be reduced then I suppose the function should be 
> broken up into smaller functions. The problem is, as I see it, little of 
> the code is reusable in other functions that also have too many nested 
> blocks.
...
> The function works and so it's logically correct but it's messy and 
> inefficient.
> 

Just on the pylint topic in general: pylint is intended to be tuned so 
that it's useful for your project, there's no expectation that it's 
perfect for every project out of the box.

If it made you think, and you agree with it that something is hard to 
read because of many levels of nesting, then sure, think about how you 
could refactor. You don't have to do that right away.

Of the different levels of commentary from pylint, this complaint is 
probably at the least critical level.  There are EXXXX errors, WXXXX 
warnings and RXXXX recommendations. Yours is an 'R'.  Take that for 
whatever it's worth...

You can make a .pylintrc file - there's an option to dump a default and 
then you tune it to turn on/off things as you like.  I'm not fond of 
using this option too much - and especially not without commenting - and 
you lose track of *why*.  Or you can put as comments in your code 
stanzas to quiet pylint on specific areas of complaint. This is usually 
better, because you've noted in the exact location of the compliant that 
"yes I mean it".  If you want to "yes I'm happy with this for now, but 
want to revisit later" you can add a TODO comment to that effect as well.

If you have really special cases, you can write pylint plugins that 
handle your situation. Usually, though, this is to check more, not less, 
though I've actually used it to define some accepted names inside a 
program as a nicer way of quieting pylint grumbles about non-PEP8 naming 
choices - I don't turn off the whole warning class, but say that this 
specific set is accepted.

Many follow a model (I wish I could with my big project!) of getting 
pylint down to silence through fixes and settings and exclusions. That 
way you have a very clear notice when a change introduces a new warning 
- in other words, you get yourself to where you're only looking at deltas.