Pylint false positives

[Steven D'Aprano]

On Fri, 17 Aug 2018 11:49:01 +0000, Jon Ribbens wrote:

> On 2018-08-17, Steven D'Aprano <steve+comp.lang.python at pearwood.info>
> wrote:
>> On the other hand, your objection to the following three idioms is as
>> good an example of the Blurb Paradox as I've ever seen.
> 
> Do you mean the Blub Paradox? If so, you're misunderstanding or at least
> misapplying it.

Yes, that was a simple typo, and no, I'm not misunderstanding it.

You're looking up the ladder to a more powerful technique available in 
Python (methods as first-class values capable of being manipulated like 
any other object) and dismissing it in favour of mindless boilerplate 
containing duplicated code, and requiring oodles of copy-and-paste 
programming to maintain.

Graham used the "Blub Paradox" to describe programmers' failure to 
understand more powerful features available in languages they didn't use, 
but there's no reason why this failure applies only to comparisons 
between languages. It also applies to arguments about idioms within a 
single language. That's the Blub Paradox too, even though only a single 
language is involved.


>>>   * code running directly under the class definition 
>>>   * creating a method then changing its name with foo.__name__ 
>>>   * poking things into to the class namespace with locals()
>>
>> Each of these are standard Python techniques, utterly unexceptional.
> 
> I guess we'll have to agree to disagree there.


>> "Code running directly under the class" describes every use of the
>> class keyword (except those with an empty body). If you write:
>>
>>     class Spam:
>>         x = 1
>>
>> you are running code under the class. This is not just a pedantic
>> technicality,
> 
> Yes, it absolutely is, in this context. Having code other than
> assignments and function definitions under the class statement is
> extremely rare.

Its rare because it isn't needed often, not because it is broken or 
dangerous or illegal or fattening.



[...]
>> You might be thinking of the warning in the docs:
>>
>>     "Dynamically adding abstract methods to a class, [...] [is] not
>>     supported."
>>
>> but that is talking about the case where you add the method to the
>> class after the class is created, from the outside:
> 
> Yes, I was referring to that. You may well be right about what it means
> to say, but it's not what it actually says.

*shrug*

It was obvious to me that it wasn't talking about methods dynamically 
inserted inside the class body since ALL methods are dynamically inserted 
inside the class body. If that was what it meant, it would be saying that 
abstractmethod never works. Clearly that's absurd, since it does work. So 
why interpret it as saying something absurd instead of using a bit of 
common sense and knowledge of how Python words to interpret it correctly?

Inside a class (or at the global scope) there is no meaningful difference 
between these:

    spam = eggs

    locals()['spam'] = eggs



>>> (Not to mention your code means the methods cannot have meaningful
>>> docstrings.)
>>
>> Of course they can, provided they're all identical, give or take some
>> simple string substitutions.
> 
> Hence "meaningful".

They can still be meaningful even if identical.



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