"Paul Rubin" <phr-n2001d@[...].com>  wrote in message
news:7xzo68s63o.fsf@[...]..
>  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.

At the start of this thread, your post implied that 'data hiding' meant
something similar to C++ or Java's access specifiers: private, public, etc.
But the stuff you mention above has nothing to do with that! The applet
sandbox is a specific mode provided by the runtime - and rexec/bastion is
NOT a hack, it's just another way to implement a sandbox.

As far as security - well, I don't know how stuff like that is supposed to
work, but in my experience that's an OS issue rather than a language issue.
Python compiles and runs on almost every platform under the sun, and lots of
them don't have ANY kind of security, so what should it do? Implement some
gigantic code-access security features that most people don't need?

And in any event, C++ access specifiers don't do much but provide a
challenge to those "rogue programmers" you mentioned, and they don't help at
all in any of the above situations. So I'm curious what you really mean, and
what you really want.

-Chris



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