[marklgr]

> The feature is just some syntactic sugar.

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.

[masklinn]

It's not an implementation detail, it is a deliberate, specified and documented feature of the language dedicated to namespace conflict resolutions in the context of inheritance.

ref: https://docs.python.org/2/reference/expressions.html#atom-id...

ref: https://docs.python.org/2/faq/programming.html#i-try-to-use-...

[marklgr]

It's so crude that, again, it looks like implementation details having been promoted to specs. Field visibility and name mangling done with very magic underscores just doesn't look right, to me.

[masklinn]

> Field visibility

It has nothing whatsoever to do with field visibility.

[marklgr]

The single leading underscore?

[masklinn]

Is conventional, it doesn't do anything at the language level.

[marklgr]

Which is my point, it's still roll-your-own, with some magic when necessary. I don't want to make a fuss about it, I mean, it's great for tinkering or small projects, but I prefer when my compiler works harder for me and actually enforces what is intended (bar some runtime reflection for very special cases).

[guyzmo]

Yes! Exactly! I added the py3 links of those in my big lengthy parent comment, so people get twice the chance to RTFM !

[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".