Pylint false positives

[Chris Angelico]

On Sun, Aug 19, 2018 at 11:54 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Chris Angelico <rosuav at gmail.com>:
>> 2) You can't identify these objects as being of the same type (since
>> they're not).
>
> That's a feature, not a bug. Type membership checking goes against
> duck-typing.

Oh, so it would be better for Python if every integer object were an
instance of a unique type, all of them called "int"? Duck typing does
NOT mean "having lots of identical type objects". You can argue that
it's an insignificant flaw to have the duplicate types, but it's
certainly not a virtue.

>> 3) Every invocation of method() has to execute the class body, which
>> takes time.
>
> That's what happens with every method invocation in Python regardless.

No. You have to execute the *class body*. Every method invocation has
to execute a function body. Yours includes a class definition.
Remember: The 'class' statement is NOT a declaration. It is an
executable statement.

>> At the price of a very small amount of encapsulation, you can make it
>> actually an inner class:
>>
>>     class Outer:
>>         class Inner:
>>             def __init__(self, outer):
>>                 self.spam = outer.quarantine
>>
>>         def method(self):
>>             return self.Inner(self)
>
> Sure, there are ways to avoid closures, but the expressive price is
> usually higher than the supposed performance gain.
>
>> Now all instances of Inner are actually instances of the same type.
>> It's still local to the class, just not local to that method.
>
> Locality to the class is usually not worth the trouble. It's good enough
> to have names local to the module.

Oh, even easier then. You don't need any of this locality. Which means
the inner class is buying you a whole lot of nothing.

>> None of this explains your aversion to creating functions in a loop at
>> class scope, while still being perfectly happy doing so at function
>> scope.
>
> It had to do with populating a namespace programmatically using strings
> as field/method names (which, generally, you shouldn't be doing).
> Defining functions and classes dynamically during runtime is perfectly
> ok.

Hmm... so it's fine to create a class at run time, but it's not okay
to define its methods at run time. I'm seriously confused here as to
what you gain by that. How is it of value to create a new class at run
time, but to require that all its methods and attributes be
hand-written in the source code, and thus completely fixed?

ChrisA