"El Pitonero" <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
