Why does python not have a mechanism for data hiding?

[NickC]

On May 25, 8:01 pm, Fuzzyman <fuzzy... at gmail.com> wrote:
> > Python was not really written with 'difficult' customers in mind ;-)
>
> True. It's extremely suited to what we do though.Minor difficulties
> like this are vastly outweighed by advantages. The difficulties are
> real though.

It's interesting to take a look at some of the work Brett Cannon has
done trying to come up with a sandbox for executing Python code that
actually manages to block access to dangerous functions like file() or
urllib.urlopen(). Powerful introspection capabilities and restricted
access to methods and attributes don't really play well together.

http://svn.python.org/view/python/branches/bcannon-objcap/securing_python.txt?rev=55685&view=markup

(I believe that work is on hiatus while he's been busy with other
projects, such as a more flexible Python-based reimplementation of the
import mechanism that would be make it possible to implement the
security restrictions needed to permit limited imports in a sandboxed
interpreter)

> > One could largely hide private vars with a program that substituted random
> > names for single _ names, and removed the doc strings for functions,
> > classes, and methods with such names.
>
> We need to *use* those names to display the spreadsheet once the
> calculation has finished (and their code has run).
>
> > Such a program could even put such names in a separate module imported as
> > '_private_do_not_use_'.
>
> Splitting more of the functionality out is probably part of the best
> solution.

Yeah, at this point your only hope is going to be making them go
through such wild contortions to get at the internal data they think
better of it. Actually blocking all access to something written in
Python is fairly tough (you generally need an extension class written
in non-Python code that hides access to certain attributes).

Cheers,
Nick.