[alptrv]

Well, that depends on your starting point, if you're a private state proponent then it may be a hack for you. I'm more of a control freak and I'm on a side of 'everything is public, lets code by interface', so for me private state is a bit of a hack that some languages have because some other languages have it and and some other languages have because it was introduced in languages before them. My point was that the lack of private state in Python didn't made impossible to separate inner implementation from public interface.

Why not make everything global? For obvious reasons - modularity, memory consumption, and inconvenience of lengthy variables names.

[ww520]

If you are a control freak and you are writing a library, you would want to control how and where people can call your code. Most languages support private function because it has found to be a good idea. Sure most of them are doing it as a hack.

[alptrv]

It is exactly the point where our interests collide - when I'm using your library, I want to have a control over your library, because I'm using it. I don't want you library to control me an the way I use it. It's a tail wagging the dog analogy.

For example I use your library and everything goes great until I'm stuck because I need to have an information hidden in a private field, if I'm in Python I would do it and add a note, fixme, todo, whatever that this is a hack and things may break in a future, but my code would work right now. And I can fork your library later and submit changes. If this is a language with real private support the only way is to use hacks (reflection) which is the same as using the field directly like in python just with some additional PITA, or to fork your library and maintain it until you merge changes, or if you not, I have to maintain it forever.