Another scripting language implemented into Python itself?

[Cameron Laird]

In article <M5lJd.23911$Qb.10090 at edtnps89>,
Orlando Vazquez  <ovazquez at gmail.SPAM.com> wrote:
>Jeff Shannon wrote:
>
>snip
>
>> Because you cannot make Python secure against a malicious (or ignorant) 
>> user -- there's too much flexibility to be able to guard against every 
>> possible way in which user-code could harm the system. Parsing your own 
>> (limited) scripting language allows much better control over what 
>> user-code is capable of doing, and therefore allows (at least some 
>> measure of) security against malicious code.
>
>I don't see how that would equate to something that the original 
>programmer should be concerned about. You could include a bit in your 
>licensing scheme that voids all support on code that has been modified 
>in any way. You shouldn't be obligated and no one expects you to support 
>something the end-user has mucked with.
>
>You could trivially enforce this by keeping checksums of all the system 
>files.
>
>In any case, there's nothing you can really do to "secure" your code. 
>This is true of any language, C, C++, and especially scripting languages 
>like Python. Anyone who has the determination get at and modify the code 
>probably will.
>
>The only time where I can see someone using another language in place of 
>Python for a scripting language is just domain-specific factors, e.g. if 
>you need the extension language to be easily used non-programmers.
			.
			.
			.
I think there's a bit of "talking past" each other.
There's a serious issue here that I suspect Mr. 
Vazquez misunderstood.  I'll try to illustrate:

The original poster wants to work in Python.  That's
fine.  Several of us have suggested he further
expose Python itself to his end-users as an extension
language.  That certainly is feasible.  He needn't
explain all of Python to those end-users--probably 
only a bit about "assignments", control structures,
and maybe lists.  

That approach creates a sort of fragility, though.
Python includes, along with much else, os.unlink().
Suppose our original poster doesn't want end-users
to be able to delete files (or directories ...).
That particular design decision is NOT particularly
apt for a licensing specification, much as I generally
favor trust in the latter; don't-delete-filesystem-
entries is simply too low-level to admit good 
expression in legal language.  More broadly, the 
model of "end-users mucking around" captures the
range of concerns only poorly.

This is a serious issue.

It's also one that brings Tcl, mentioned several
times in this thread, back into focus.  Tcl presents
the notion of "safe interpreter", that is, a sub-
ordinate virtual machine which can interpret only
specific commands.  It's a thrillingly powerful and
correct solution to the main problem Jeff and others
have described.