I learned this trick when I first picked up Python, too. I came from Java and, naturally, started writing Python code in the style I had learned to write Java: Heavily object-oriented, with getters and setters everywhere.

Eventually, though, I stopped trying to program in Java in Python. Once you relax and stop trying to hide your precious instance variables from all of the potentially pernicious or incompetent programmers who might be using your code (usually, in my case, just me), you no longer need tricks like this. And you realize that you never really needed them to begin with.

And you can turn your member access into called code when you need it:

    class Foo(object):
        @property
        def bar(self):
            print "Running getter"
            return self._bar
        
        @bar.setter
        def bar(self, value):
            print "Running setter"
            self._bar = value

I'm not advocating using getters/setters in Python. Just pointing out that you can access "private" members. I don't typically use getters and setters in JavaScript either.

Java, on the other hand, kind of forces you into using getters and setters because the POJO is so ingrained into the ecosystem. That said, if you write Android apps in Java, you should avoid getters and setters because they aren't really necessary and they create extra overhead.

One of the first textbooks on PL/1 also stated: "you should avoid using subroutines because they they create extra overhead" ;)

40 years later and we still there ...

Agreed. I can't think of a time when you'd need to use it either (and I wrote the post). But, coming from working in Java for the past few years, it seems pretty cool that you can do it.

You also can do it in java: http://www.fordevs.com/2008/11/reflection-is-mechanism-by-wh... . As a python programmer who never uses "private" variables (I use a single underscore to indicate fields that shouldn't be used), I'm a bit torn as to which private variable abuse method is uglier :)

They are nice to know when debugging -- looking at dir(obj) can lead to things like "where the heck is _foo__attr defined?" if you don't know the __x -> _classname__x mangling.

Same here. Like many things in python, the unconventional hack is made just inconvenient enough to persuade most people to rethink their strategy.