In the many Python applications I've created, I often create simple modules containing nothing but constants to be used as config files. Additionally, because the config file is actually a Python code file, I can add simple logic for changing variables depending on a debug level, etc.
While this works great for internal applications, I'd be wary about releasing such applications into the wild for fear of someone either accidentally, or maliciously, adding destructive code to the file. The same would hold true for using Python as an embedded scripting language.
Is there a subset of Python that is deemed "safe" for embedding? I realize how safe it can be considered is fairly subjective. However, Java Applets and Flash both have their security sandbox well defined. I'm wondering if there's a version of Python that has similar rules?
EDIT: I'm asking not so much because of the config file approach, but because I'm interested in implementing some scripting/plugin mechanisms into a newer app and don't want a plugin or script to be able to, say, delete files. That goes beyond the scope of what the application should be able to do.
The pypy project offers sandboxing features, see http://doc.pypy.org/en/latest/sandbox.html .
The PyMite VM fits the bill if all you need to do is set simple variables, loops, conditionals and functions. PyMite is tiny, written in C, uses a static memory pool and can be embedded. It has an extremely limited set of builtin functions that is easy to configure. Similarly, the only standard libraries are partial implementations of string, dict, list and sys. The PyMite VM is part of the python-on-a-chip project, so it was designed to run on microcontrollers, but can run on posix-style desktop systems. The downside is that PyMite is not as extensively de-bugged as other Python implementations.
Here are a couple of links to give you an idea on what you're up against:
There is also a dead google code project at http://code.google.com/p/sandbox-python/
AFAIK, some attempts were made in standard python library, but they were not successful. See Restricted Execution for details.
Your native code that's "in the wild" is equally vulnerable to this attack; that it is in machine code is just a speed bump, and no security.
If you are extremely paranoid and want a higher speedbump, you could make your native app that hosts the script instance check a hash of the content. Then accidential changes are impossible; only deliberate changes would go to the trouble of updating the checksum. You could go further and check they were signed with a public key too; then only hacking your native app could let new scripts in.
But the sandboxing? Don't worry about it!
You might try IronPython on Silverlight/Moonlight, as these guys impressively seem to be doing. There is a lot of great information on these types of IronPython applications from the Resolver One developers here.