Peter Wang <pzw1[nospam]@hotmail.com>  writes:
>  i don't think data hiding's purpose is to keep rogue programmers in
>  line.  it's partly to insulate imperfect development practice (e.g.
>  sloppy documentation) and partly to define an interface for a class.

Keeping rogue programmers in line is a perfectly legitimate use of
data hiding.  For example, look at java applets on web pages.  These
have to run in the same JVM as parts of the browser, and yet the
applets can be hostile.  So the language has to protect the browser
internals from the loaded applets.  Another example is security
interfaces where the class instances contain authentication
credentials and the application should be able to use them but not
copy them.

Python provides a restricted execution hack (rexec/bastion) to deal
with the applet situation, but it's a pain for the second situation
because you have to wrap the caller in the rexec shell, rather than
wrapping the secure object in a security shell and leaving the caller
unrestricted.

The best way I've managed to deal with this is to put the secure
objects in a totally separate process and access them by RPC.
That, too, is a kludge, though.
-- 
http://mail.python.org/mailman/listinfo/python-list