Why less emphasis on private data?

[Paul Rubin]

Steven D'Aprano <steve at REMOVE.THIS.cybersource.com.au> writes:
> > I have no idea how often if ever.
> 
> You've established that there's a name conflict when you do so, which
> leads to bugs. So how often do you get bitten by that particular type of bug?

I don't know.  Likely zero, possibly not.  I'm sure I've written many
bugs that have never been detected by me or anyone else.  I've
probably written bugs that crashed an application for some user but
they just cursed me out and never bothered to tell me about the crash.
Maybe I've even written bugs that leaked a user's private data without
the user noticing, but discovered by some attacker intercepting the
data who is cackling about the bug while keeping it secret.  There's
no way for me to think I'll ever find out.

I'd much prefer to be able to say of any type of bug, "the number is
exactly zero as a known fact, because it's inherent in Python's design
that it's impossible to have that type of bug".  Language designs
should aim to let programmers say things like that as often as possible.

> class MySubClass(SomeSuperclass): ...
>         raise ValueError("Name conflict with private attribute!") 
> Problem solved.

No good, Python allows creating classes and attributes on the fly.
The superclass could create its private variable after the subclass is created.

> The truth of the matter is, MyClass.__private is not private at all. It is
> still a public attribute with a slightly unexpected name. In other words,
> if you want to code defensively, you should simply assume that Python has
> no private attributes, and code accordingly.
> 
> Problem solved.

Well, "problem moved", not "problem solved".  Now you have the problem
of having to know the names of every attribute any related class might
use when you write your own class.  That is why other languages have
private variables and Python has name mangling--to solve a real problem.
Except Python's solution is a leaky kludge.