In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> 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.
--
http://mail.python.org/mailman/listinfo/python-list
