[guyzmo]

Yes, it is intended and fully part of the philosophy behind the language's design (as shown in PEP-20, aka the Zen of Python):

> Explicit is better than implicit

So there's no "leaking" of implementation details, because the implementation shall always be fully exposed.

As said in a sibling post, the private fields are just public fields, which are not documented as part of the public API and start with a `_`.

And as I said in the parent post, the reason to use the name mangling mechanism on top of that is to ensure that those variables won't be used by descendants in the class hierarchy, when a given class is intended to be subclassed by a peer.

The the sugar /is/ actually sugary-sweet-yummy, as it's preventing potential faults from people who blindly subclass stuff they haven't read the source code of.

[marklgr]

I get full well what it does, but I find the syntax "magic" and not very attractive. Why no special keyword for visibility, proper namespaces etc.?

In c++ and likes, I know there's a vtable somewhere, and I get why there must be one for virtual funcs, but I don't want to deal with it directly, it's the compiler job. Same for Python, I know it must prevent fields from getting clobbered when inheriting, but I don't want to be exposed to its mangling or whatever other mechanism it uses.

[masklinn]

> Same for Python, I know it must prevent fields from getting clobbered when inheriting, but I don't want to be exposed to its mangling or whatever other mechanism it uses.

Python does not prevent anything, it gives the developer a name mangling tool, it's up to the developer whether they want to use it or not. By default, identical names will conflict and you will clobber supertype fields or methods.

[marklgr]

Again, that's very Perl-ish, to me. "Here are some tools and tricks, use them to do your own OO if you want--but you can easily bypass it all every time you wish".