Virgin keyword (Was: Will python never intend to support private, protected and public?)

[Roy Smith]

"El Pitonero" <pitonero at gmail.com> wrote:
> Python's lack of Java-style "private" surely has its drawback: name
> collisions can happen. But, that's just one side. Name collisions are
> allowed in many dynamic languages, where you can override the default
> system behavior (in some languages, you can override/intercept the
> assignment operator "=", or even the "if" statement and the "while"
> loop.) Sure, in these very dynamic languages you can ACCIDENTALLY
> override the default system behavior. How many Python programmers have
> once upon a time done stupid things like:
> 
> list = 3
> 
> , without realizing that list() is a Python function? This type of
> accidental overriding DOES happen. Similarly, in large and complicated
> Python projects, name collision (even for "self._x" type of private
> members) CAN happen, and I am sure it has happened for some people.

I think everybody would agree that accidentally overwriting a name because 
you didn't realize it was defined in an enclosing context is a Bad Thing.  
The classic (C++/Java) solution has been to have classes protect their 
members from outside exposure.

I wonder if a better solution would be to have the protection applied from 
the other end?  Imagine if we had a "virgin" keyword which could modify the 
assignment statement to assert that the name being assigned to was not 
currently in use.  Thus

virgin x = y

would be treated sort of as if it had been written (ignore, for the moment, 
the possible side effects of the extra eval of x)

try:
   x
except NameError:
   throw ChastityError
else:
   x = y

This would provide you protection from stomping on names by accident, but 
it would allow you to stomp all you wanted if you wanted to.