Invoking Python from Python

[Cameron Laird]

In article <86acgeaagx.fsf at bhuda.mired.org>, Mike Meyer  <mwm at mired.org> wrote:
			.
			.
			.
>Since Cameron didn't provide examples, let me grab a simple one. The
>cheetah templating system works by creating Python programs from the
>template. The programs, when run, output the "filled in" template. The
>templates are generally more maintainable than the raw python - even
>if you cleaned up all the things Cheetah does to make writing
>templates easier. This model makes it possible for Cheetah templates
>use inheritance - they can inherit from each other, from python
>classes, and python classes can inherit from them.
			.
			.
			.
Good example.  Excellent one, even, for emphasizing the place
of inheritance in the design.

Functionalism, space-time, security, persistence, duality, ...
I have trouble talking in this area without starting to froth.
An unsatisfying treatment of some of these issues appears in
<URL: http://www.unixreview.com/documents/s=9884/ur0509m/ >.

I'll rein myself in and suggest an even easier introduction
to this subject:  configuration files.  RARELY is the correct
answer to create a new syntax, although many development
organizations give the impression that's their first choice.
".ini"-speak is a safe-enough choice.  Most interesting,
though, is to interpret Python or some subset as a configu-
ration specification, so that one has immediately not just
    HOME = "/some/folder"
    STEP_LIMIT = 16
but 
    pool_size = cpu_count * 30
and even
    if today == "Sunday":
        total_process_maximum = 8
available in the configuration language.  Neat, eh?  

But if configuration is *that* powerful, then it can also
do great damage.  How does one make Python interpretation safe?

That's a subject for another day.