Pylint false positives

[Steven D'Aprano]

On Fri, 17 Aug 2018 15:19:05 +0200, Peter Otten wrote:

> You usually do not want many identical (or very similar) methods because
> invoking the right one is then errorprone, too, and you end up with an
> interface that is hard to maintain. At some point you may need to
> introduce subtle changes to one out of ten methods, 

These hypotheticals are fairly tedious. "At some point you might..." 
yeah, you might, but you probably won't, and in the meantime, YAGNI.

And if you do, it is easy to do: pull the special method out of the loop. 
Or add code to modify it after the loop.

Or make the changes in a subclass.

We do these things *all the time* for data objects, creating them in a 
loop then modifying those that need modifying. There is *no difference* 
here: methods can be treated as data objects too.


> and later someone
> else may overlook that specific angle in the documentation...

You say that as if people never failed to read the documentation about 
"regular" methods that are made by hand in the conventional way.



> If you have many similar methods you should spend your time on reducing
> their number rather than to find shortcuts to automate their creation.

The assumption here is that the basic design is sound. Why do you assume 
it isn't?

According to the OP Frank, this design has been in production for many 
years and works well. While I personally have some reservations that 
using subclasses is the best solution, I'm willing to give him the 
benefit of the doubt rather than insult his competence by assuming it is 
a broken design without ever seeing the code.



> Programming is not only about avoiding duplication, it is also about
> stating your intents clearly.

Indeed. And what states the intention "These methods are identical except 
in their name" more strongly than creating them in a loop?



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson