Pylint false positives

[Steven D'Aprano]

On Mon, 20 Aug 2018 15:58:57 +0300, Marko Rauhamaa wrote:

[...]
>> The point is that creating a class object every time you want a closure
>> is pointlessly wasteful. There is *no benefit whatsoever* in doing
>> that. If you think there is, then it's probably because you're trying
>> to write Java programs in Python.
> 
> The benefit, as in using closures in general, is in the idiom.

Yes, but you get closures by nesting functions, not by nesting classes.

We don't *inherently* have to duplicate Java style nested classes in 
order to get the container of closures you mentioned earlier. We don't 
have to duplicate the idiom exactly, if it doesn't match the execution 
model of Python.

On the other hand, there's no need to optimize this if it isn't critical 
code in your application. As I have often said, the question isn't 
whether Python is fast or not, but whether it is *fast enough*.

If you are aware of the potential pitfalls, and the code is fast enough, 
and refactoring it to something faster and less pitfall-y is too 
difficult (or not a priority), then that's fine too.



>>> But now I'm thinking the original Java approach (anonymous inner
>>> classes) is probably the most versatile of them all. A single function
>>> rarely captures behavior. That's the job of an object with its
>>> multiple methods. In in order to create an ad-hoc object in Python,
>>> you will need an ad-hoc class.
>>
>> An important difference between Python and Java here is that in Python
>> the class statement is an *executable* statement, whereas in Java it's
>> just a declaration. So putting a class statement inside a Python
>> function incurs a large runtime overhead that you don't get with a Java
>> inner class.
> 
> The same is true for inner def statements.

Indeed. Inner def statements are not very useful (in my opinion, although 
I believe Tim Peters disagrees) unless they are used as closures. The 
biggest problem with the idea of using inner functions in the Pascal 
sense is that you can't test them since they aren't visible from the 
outside.



> I don't see how creating a class would be fundamentally slower to
> execute than, say, adding two integers.

Well, fundamentally adding two integers could be as quick as a single 
machine instruction to add two fixed-width ints. CPUs are pretty much 
optimized to do that *really quickly*.

Creating a new class requires allocating a chunk of memory (about 500 
bytes in Python), calling the appropriate metaclass, setting a bunch of 
fields, possibly even executing arbitrary metaclass methods. Its not as 
expensive as (say) listing the first trillion digits of pi but it surely 
is going to be more costly than adding two ints.


[...]
> Anyway, in practice on my laptop it takes 7 µs to execute a class
> statement, which is clearly worse than executing a def statement (0.1
> µs) or integer addition (0.05 µs). However, 7 microseconds is the least
> of my programming concerns.

And fair enough... premature optimization and all that.




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