Self Hell in Python

I find the self in the method call parameters slightly awkward, but other than that I like writing a lot of 'self'. One of the biggest reasons I prefer Python to Ruby or Perl is that I really agree "Explicit is better than implicit.", and adding the self before your instance variables and method calls explicitly labels their namespace/scope, and I don't find it too distracting. I sometimes do it in Java too, prefixing instance variables and method calls with 'this'.

I do agree that OOP approaches can be a bit overused (especially if someone's been coding too much Java), and I've always appreciate that Python doesn't shove it down your throat. I like that you can lean towards more functional code like this example, or towards simple imperative code. But when I do want some classes, I find the Python mechanism mostly ok.

The author points to this line as the main culprit for self-hell:

  self.minimum, self.maximum = min(self.minimum, self.maximum), max(self.minimum, self.maximum)`

This line is needed to 'defensively protect the input'), i.e. try to compensate when minimum and maximum arrive out of order. Firstly, I can't understand exactly why this defensive protection is not done before assigning the attributes, i.e. simply:

  # not too hellish, more readable on two lines
  self.minimum = min(minimum, maximum)
  self.maximum = max(minimum, maximum)

Secondly, I'm not very up on my Python Zen, but I think this naming of arguments followed by defensive protection isn't particularly Pythonic anyway. How about something like this?

  class Window(object):
       def __init__(self, x1, x2):
           # pass your dimensions in any order
           self.minimum = min(x1, x2)
           self.maximum = max(x1, x2)
       def __call__(self, x):
           return self.minimum <= x <= self.maximum

Note that the name "self" is a convention, not a requirement. If it's just the amount of keystrokes that you're concerned about, name it something else like "o".

Of course, good luck having someone else understand your code...

Trying to avoid self in Python is just no good idea. You just break one basic convention of Python just because you don't like one thing in Python.

I would recommend to the author of the article one of those things:

  (a) either find a programming language, where you like everything (I guess, unlikely)

  (b) or write your own programming language

After some years in the business, I have learnt, that every programming language has its own "hell".

Some hells are hotter, some are relatively mild. When you try to avoid every hell, you will end up writing your own programming language ... and be very lonely for the rest of your computer-life.

Pythons oddities are one of the mildest I have found yet, IMHO.

After 5 years of Python, I don't even see self anymore (how zen).

Author could have written

    class Window(object):
        def __init__(self, min, max):
            if min > max:
                min, max = max, min
            self.min = min
            self.max = max

to avoid repetition. If many args are needed,

    def __init__(self, a,b,c,d,e,f,...):
        for k, v in locals().items():
            setattr(self, k, v)

Etc etc there are endless idiomatic ways to avoid boilerplate in Python

My problem with inner functions is that you can't create a unit test for them. They're inaccessible.

I would propose making your inner function into a classmethod and moving away from the state of the class. This structure is well defined and is easily testable.

Alternatively, assuming you feature doesn't get more complicated, you can make your min-max ordering happen in one line:

    self.minimum, self.maximum = sorted((minimum, maximum))

I think you can avoid self hell through careful programming.

It's true that people tend to force OOP onto python, especially when coming from other languages. But I think it's good to mention that in certain cases, keeping state by building a class is necessary, or at least easier than using a module-based approach.

  > The double checking costs a few CPU cycles but saves a lot of keystrokes.

Not sure I agree with this, idiomatic python should be explicit, even if it means more keystrokes.

Once Python got nested scoping, 'class' became redundant. It's a nuisance not just because of all the selves: say you started with

    def make_window(x1, x2):
        lo, hi = sorted((x1, x2))
        def window(x): return lo <= x <= hi
        return window

and decided to give the window a custom repr. You could write

        window.__repr__ = lambda: '<%s..%s>' % (lo, hi)

but this sort of thing gets less fun the further you take it. So you actually rewrite all of this code with 'self' and '__init__' and it gets much longer and if you're me you conceive an antipathy to classes. What I wish you could write is

    def make_window(x1, x2):
        lo, hi = sorted((x1, x2))
        def window:
            def __call__(x): return lo <= x <= hi
            def __repr__(): return '<%s..%s>' % (lo, hi)
        return window

BTW, 'foo hell' is too strong a term for most real foo in programming -- we don't need more encouragement to split into warring tribes.

Python is my favorite language, but I think that explicitly having to pass self to methods was a huge mistake. It's a gotcha that catches even experienced programmers, the error message is confusing and unhelpful, it's verbose, and the one case it allows (calling the class directly instead of the instance?) is not generally that useful. It makes some metaprogramming stuff slightly cleaner sometimes, but that's not a great justification.

The author is right in that you should use iterators and generators whenever they are a elegant solution.

I do not think, that you should use nested functions that often, as already mentioned, they are hard to test.

You get more readable and testable code, when you put the code in a new method or in another class instead. You end up with less lines per method and you can pass the data explicitly, getting rid of the self.

Huh, the last thing I would have expected to see on HN. My apologies for the generally muddled writing, this was one of my oldest posts.

The body of your second version of __init__() in one line:

self.min, self.max = sorted((min, max))

This may be what was meant with the sentence that claims "but eventually you'll need a line like this outside of init" but I'm not sure what that part means. (I generally support functional programming practices, which Python leaves a lot of room for).

Or, you could subclass tuple.

This is just a bad example. I would use a closure here for the simple fact that it's simpler. No need to create an extra class with __call__ magic when you can just return a closure.

Now, if you're doing something more complex, a class complete with self parameters is simply unavoidable.

Spoiler: he does not just advocate for not using 'self', he goes as far as advocating for not using objects at all and use closures instead.

Anyone that wants to read more theory surrounding this should read a fantastic 2006 paper called 'Out of the Tar Pit'. It's available on the "papers we love" gh repo [1] and basically covers the issue of state and how it always adds avoidable complexity (and thus how you can avoid complexity by taking an alternative route).

[1] https://github.com/papers-we-love/papers-we-love/tree/master...

If it is too tiresome to write one more argument:

    class window:
        @staticmethod
        def __init__(min, max):
            window.min, window.max = sorted((min, max))

        @staticmethod
        def __call__(x):
            return window.min <= x <= window.max

Or if you are just bored of self:

    class window:
        @classmethod
        def __init__(cls, min, max):
            window.min, window.max = sorted((min, max))

        @classmethod
        def __call__(cls, x):
            return window.min <= x <= window.max

But my favorite is:

    window = lambda *args: (
        lambda (min, max)=sorted(args):
            type('', (), dict(min=min,
                              max=max,
                              __call__=lambda _, x: min <= x <= max))()
    )()

If "self" is a hell, it's such a super tiny small hell that I'm happy that's the worst thing someone has to say about it. I do think it's nice when it comes to class methods vs instance methods, being clear that there is nothing called "self" in the method, etc. Further, it's a nice indication of what OO is at a very very basic level - method organization that takes a self as a first argument.

I kind of like what Ruby did with "@" instead, but dislike some of the other syntactic choices.

Now, say, Python metaclasses -- there's a language feature I don't like.

Isn't there an issue in Python where closures don't work as expected? The following code will blow up:

https://gist.github.com/skatenerd/72281cadd2ae3e44d6cf

For some reason, stashing the variable inside of a list will fix the variable resolution..?

http://stackoverflow.com/questions/4851463/python-closure-wr...

Okay, so if we're talking crimes against Pythonicity, how about avoiding self while still using a class?

    def Window(x1, x2):
        minimum = min(x1, x2)
        maximum = max(x1, x2)
        class _(object):
            def __call__(_, x):
                return minimum <= x <= maximum
        return _()

The trick here is that the object instance takes values from its creating context as closure variables, rather than constructor parameters. Hence, it doesn't need a constructor at all, or any self references. It doesn't even need to use the self parameter it implicitly receives - hence why i can call it _ even though Peter Norvig couldn't! I've also called the class _, partly because it's sort of throwaway, in that it's never referred to after the instantiation which immediately follows its declaration, and partly just to wind people up.

You can do this in Java too, using an anonymous class to avoid having to use a throwaway name, as long as the object you're creating implements an interface:

    public static Function<Double, Boolean> Window(double x1, double x2) {
        double minimum = Math.min(x1, x2);
        double maximum = Math.max(x1, x2);
        return new Function<Double, Boolean>() {
            public Boolean apply(Double x) {
                return (minimum <= x) && (x <= maximum);
            }
        };
    }

Neither of these are outlandish hacks; rather, they illustrate the fundamental connection between objects and closures.

In particular, the Java version is extra comical because the interface being implemented is functional, so there is a mechanical transformation (that my IDE will do for me!) which evaporates the anonymous class and uses a naked function, in the form of a lambda, just as the OP advocates:

    public static Function<Double, Boolean> Window(double x1, double x2) {
        double minimum = Math.min(x1, x2);
        double maximum = Math.max(x1, x2);
        return x -> (minimum <= x) && (x <= maximum);
    }

I like self. It's explicit.

An excellent counterpoint to object-oriented thinking.

@staticmethod?