Pylint false positives
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Fri Aug 17 14:47:34 EDT 2018
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
More information about the Python-list
mailing list