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

[Paul Rubin]

Mike Meyer <mwm at mired.org> writes:
> > What convention?  It just makes it possible to write code with some
> > specific invariants if there's a need to do so.
> 
> That you don't pass private variables to a function unless it's a builtin.

No, I don't see that as "convention", it's just something that you do
if you want to make sure that all the references are local or
builtins.  It's like saying that if you if you want to be sure that x
is always positive, then don't execute statements like "x = -3".  I
wouldn't call something like that a "convention".

In C, one can easily crash an application by derefencing a null
pointer, or break type safety by freeing something twice or setting an
array element with an out-of-range index.  In Python, those failures
are supposed to be impossible.  Not "inconvenient", but impossible.
We usually think of that as a good thing, not a symptom of bondage and
discipline.  But (not even bothering with private instance variables
or builtins), if I say

   def g():
     for i in (1,2,3,4,5):
       yield i
   x = g()

maybe I'd like to be sure that x never yields negative numbers.
CPython happens to have some features that stop me from guaranteeing
that invariant.  A CPython script that makes x yield negative 3 is
contorted but not impossible.  Whether the existence of those hooks is
a good thing or not, I don't see them as a fundamental characteristic
of Python.  Python without those hooks would still be Python.  And I
don't see why wanting to be able to guarantee that impossibility is
somehow more B&D than wanting to guarantee the impossibility of null
pointer dereferences.

> Except that, with Python as it exists today with a private keyword
> added, it's *still* everyone.  The only convention breaking the private
> keyword would allow the compiler to catch is a reference to
> foo.private. 

Well, it would be done at runtime by __getattr__ or the like.

> It wouldn't catch overriding things in __builtins__ or
> overriding builtins in a module, or things poking at the variable
> through __dict__, or - well, there are probably lots of things that
> need to be dealt with.

Yes, but I see all of those as implementation artifacts, not anything
fundamental.

> Preventing accidents is all "private" does - without fundamental
> changes to the implementation of the language. You have to catch every
> mechanism that can be used to find a reference to an attribute, like
> references to __dict__ and to the class variable.

The Python stdlib for a long time had a module called Bastion that
attempted to do exactly that, so you can't say that the desire is
un-Pythonic.  Bastion was only removed because implementation issues
kept it from working properly.  Those issues probably can't be
resolved in the 2.x series but as the language evolves, maybe
something can be done to bring it back.