I would not call it "syntactic sugar", but rather a leak of implementation details. It could be deliberate, like Perl did for its OO (showing the entrails of all its objects), but it's not particularly sugary-sweet-yummy.
ref: https://docs.python.org/2/reference/expressions.html#atom-id...
ref: https://docs.python.org/2/faq/programming.html#i-try-to-use-...
It has nothing whatsoever to do with field visibility.
> 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.
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.
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.