In article <ddluttodf5dctdk9gk5900dqc158oo448o@[...].com> ,
 Peter Wang <pzw1@[...].edu>  wrote:

> On 30 Oct 2001 17:11:28 -0800, Paul Rubin <phr-n2001d@[...].com>
> wrote:
> 
> >Peter Wang <pzw1@[...].edu> writes:
> >> while i feel that Python makes me far more productive as a programmer
> >> for all the projects on which i've worked, i'm inclined to agree that
> >> the lack of data hiding coupled with lack of a standard interface
> >> specification would cause problems in a team.
> >
> >Well, there's cheesy data hiding in the sense that instance variables
> >whose names begin with underscores are difficult to reach from other
> >modules.  
> 
> well... kind of.  but short of naming all my private variables "_foo"
> and hacking around the problem, there's no way to prevent lazy
> programmers from touching all of your classes's data members.  i know
> this is not python's paradigm, but OTOH this is something that has to
> be dealt with in a production environment...

This brings up an issue about using underscore to hide data...

My understanding is that a double underscore is required for Python to 
automagically mangle the name. On the other hand, two postings now 
suggest that a single underscore is sufficient.

If double underscore is required, then it seems to me this is a very 
common misconception that a single is sufficient. It might be worth 
changing.

If double is not required, I'd love to know about it. Single looks a lot 
neater, and I'm not fond of double punctuation symbols that are hard to 
read anyway.

Personally, I'd like to see the variable mechanism made more explicit 
and robust, including:
- an explicit way to declare class instance variables as hidden
- a means of explicitly declaring variables (e.g. a "local" keyword), 
which implies...
- a way to turn on checking for undeclared variables (e.g. a pragma-like 
mechanism, so it can be applied to modules)
- a way to turn off the ability to add new instance variables to class 
instances (something really simple and obvious, such as a pragma)

-- Russell
-- 
http://mail.python.org/mailman/listinfo/python-list