hi chris,

i think you are confusing/interlacing my posts with Paul's. :-)  i was
not concerned with data hiding in the form of restricted execution or
the java sandbox.

in my use of the term "rogue programmer", i mean someone who displays
a lack of judgement when coding and interfacing with other people's
code.  it's primarily *not* malicious; most of the time it's because
(1) he doesn't know any better, or (2) he's under extreme pressure to
push out a feature and compromises on process as a result.  in both of
these cases, i wanted to know what sorts of language mechanisms have
been found to be useful in protecting the code base and application
from non-immediately-revealed bugs.  the overwhelming response that
i've gotten is that there is nothing in the language, and no one has
really devised any, and it is up to good process and thorough unit
tests.

which is fine, and is pretty much what i had figured.  i just didn't
want to struggle with it for a while only to find that there's a nifty
"develframework.py" module with a framework for team python
development. :-)

-peter



On Wed, 31 Oct 2001 17:35:17 GMT, "Chris Tavares"
<christophertavares@[...].net>  wrote:

> "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