[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Pylint false positives

Chris Angelico <rosuav at gmail.com>:

> On Sun, Aug 19, 2018 at 11:54 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
>>> 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.

Sorry, I was being imprecise.

Obviously, whenever you execute a def statement, you have to execute a
def statement. Similarly, whenever you execute a class statement, you
have to execute a class statement. And executing a class statement
involves certain chores. Intantiating an object involves a different set
of chores. And invoking a method involves yet another set of chores.

Some of these chores are heavier, some of them are lighter. But where I
have used Python, performance hasn't been a bottleneck. It it were, I'd
choose different approaches of implementation.

> 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.

When I first ran into Java's anonymous inner classes, I wondered why
they hadn't simply introduced anonymous functions. In fact, the whole
debacle ended up in a schism where C# forked out of Java and introduced
delegates, which are a neat concept and should have been there in C++
from the get-go. In their arms race both C# and Java finally introduced

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.

> 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?

Not completely fixed because the methods of the inner class can refer to
the variables of the outer scope.