I've worked with non-Python programmers and templating systems in the past. And I see your point about sufficient power in the templating system.
There are a number of considerations involving templating languages that do not have to do with power.
One is the nature to do a form of round trip. Can a template be given back to a designer (or designer's software) and can this designer then make adjustments without getting hopelessly confused or breaking the logic of the template all the time? Both ZPT and Twisted Woven are attempts in this direction. Lots of program code in a template can break this.
The other, which is a recent insight I'm still exploring, is how much of the program has to be exposed to the template designer at all. Most templating systems allow calling into the program's API, which can have a complex object model below it. This has two problems:
* the template designer can be exposed to lots of aspects of the API that this designer has nothing to do with. It's not clear whether the designer needs most of this information; the designer may get confused or the designer may cause parts of the program to be called that were not intended to be called from the template directly at all.
* Bugs in the software are exposed to the template designer. The template designer can create perfect template logic, and be exposed to errors in the software that have nothing to do with his own performance as a template designer. The template
designer is exposed to complex error messages in the application logic.
I think that a template designer needs enough power but should not have to deal with the junk in the underlying system so much. I also suspect the template language does not need *that* much power if the data that is fed into the template already is prepared for various circumstances; i.e. Python logic on a view.
I don't mind if the designer writes parts of the view code (outside the template), too. It will probably result in better factored templates as common expressions can disappear into simple view methods.
Most view systems are 'pull models'; API calls pull the information from
the object model. The problems I mentioned above are hard to avoid in those. There are also view systems with aspects of a 'push model'; information is pushed outside the application into a bundle that can be easily accessed by the view, and which only contains the information needed by the views. Bugs in application logic will often be exposed in the push phase, not afterwards. Streams of data will be combined before they reach the view, so it's not the job of the view to query various part of the program directly, only what is produced by the first phase.
What is pushed out can be strictly defined. XML pipeline
models such as in cocoon have push properties, and are therefore interesting in this respect. The stage before the view template produces an XML
document with the relevant information to display the view. Programmers
can debug what appears in this stage without bothering the view
developer, who only has access to the output of this stage.