Pylint false positives

[Steven D'Aprano]

On Wed, 22 Aug 2018 03:58:29 +1000, Chris Angelico wrote:

> On Wed, Aug 22, 2018 at 2:38 AM, Marko Rauhamaa <marko at pacujo.net>
> wrote:
>> Gregory Ewing <greg.ewing at canterbury.ac.nz>:
>>
>>> Marko Rauhamaa wrote:
>>>> Lexically, there is special access:
>>>>
>>>>    class C:
>>>>        def __init__(self, some, arg):
>>>>            c = self
>>>>            class D:
>>>>                def method(self):
>>>>                    access(c)
>>>>                    access(some)
>>>>                    access(arg)
>>>
>>> [...]
>>>
>>> you can do that without creating a new class every time you want an
>>> instance. You just have to be *slightly* more explicit about the link
>>> between the inner and outer instances.
>>
>> By "*slightly* more explicit," do you mean more syntactic clutter?
>>
>>
> No, he actually means "explicit" in the normal English sense. You're
> trying to use it in the python-ideas sense of "code that I like", and
> since you don't like it, you want to call it "implicit" instead, but it
> obviously isn't that, so you call it "syntactic clutter".

That's an incredible insight into Marko's internal mental state you have 
there. And you get that all from the words "syntactic clutter"? I thought 
he just meant that it was cluttered code. How naive was that?

*wink*



> But this is actually a case of explicit vs implicit.

To be honest, I don't even understand Greg's comment. With no inner 
class, what is this "inner instance" he refers to here?

    "you can do that without creating a new class every time you 
    want an instance. You just have to be *slightly* more explicit
    about the link between the inner and outer instances."


Marko wants to use closures. So how do you close over per-instance 
variables if you create the closures before the instances are created?

If we only needed *one* function, there would be no problem:

class Outer:
    def __init__(self, some, arg):
        c = self
        def closure():
            access(c)
            access(some)
            access(arg)
        # then do something useful with closure


But as soon as you have a lot of them, its natural to want to wrap them 
up in a namespace, and the only solution we have for that is to use a 
class.

Its a truism that anything you can do with a closure, you can do with a 
class (or vise versa) so I dare say there are alternative designs which 
avoids closures altogether but we don't know the full requirements here 
and its hard to judge from the outside on why Marko picked the design he 
has and whether its a good idea. It could be a case of "ooh, closures are 
a shiny new hammer, this problem must be a nail!" but let's give him the 
benefit of the doubt and assume he has good reasons, not just reasons.



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