Will python never intend to support private, protected and public?

[Paul Rubin]

Mike Meyer <mwm at mired.org> writes:
> > Yes, the point is that it's something that you can check for by
> > examining the class in question without having to examine any other
> > classes.
> 
> That's a pretty restrictive convention to follow.

What convention?  It just makes it possible to write code with some
specific invariants if there's a need to do so.

> For instance, I might want an error dialog to be a private variable
> of a class representing a window - after all, I don't want anyone
> else writing to it, or using it in any way. Except, of course, for
> any GUI framework routines I have to pass it to in order to use
> it. This problem crops up for every utility routine in every library
> I might want to use. Opening files by name, concatenatting strings
> (or are we going to have a convention that implicit invocation of
> functions with the operator syntax don't count, and another one that
> you don't overload operators with destructive functions, and so on), etc.

I just don't understand your point here.  Yes, you can do all those
things and leak any variable.  However, if you want to NOT leak some
particular variable, "private" lets you code in a way that lets you
easily confirm that you didn't leak it.

> So it turns out that getting the behavior you desire involves
> following a lot of conventions.

That improves on the current situation.  Right now the behavior is
impossible to obtain in Python no matter how many conventions you
follow, unless you follow them through a whole program of arbitrary
size instead of just in the class that you're trying to protect a
variable in.  And when you do it through that much code, it becomes
extremely hard to confirm by inspection that they're followed.  That's
why we have things like the principle of least privilege.

> File scope isn't good enough for python.
> 
> import madhouse
> madhouse.len = my_len_breaker

Ugh, yeah.  IIRC, rexec dealt with this using a special import hook
that stopped you from importing.  For an unrestricted client, maybe
there would have to be some special import that restores the builtins.

> In other words, by adding private to python, you're making it so that
> bugs involving overwriting a private attribute will involve only the
> owning classes code so long as everyone follows the conventions that
> exist about the use of such variables.

Not everyone, just the author of the class that uses the private
variable.  That's the point.

> > I don't see how pylint could know which instances to flag,
> 
> I was thinking it would flag any use of such a variable where the
> target variable wasn't "self". That may be a stronger constraint than
> you wanted - but that's good, right?

Shrug.  That might be of some limited usefulness, but all it tries to
do is prevent accidents.  And it does nothing about setattr/getattr.