MiddleKit (the ORM in Webware) uses code generation. In part it's because it preceded Python 2.2's descriptors, and would have required overriding __getattr__ in a somewhat annoying way. Well, actually it could have done it without that either... but anyway, it seemed more natural to the authors to do it through code generation.
I also know someone who built a bunch of Zope stuff that generates Python, Z SQL, and DTML (or Page Template?) code from a single model. It may seem more appealing when you are generating several languages from a single model.
I agree that it makes more sense if multiple languages are generated from a single model. Less so if you use Python to generate more Python code. If you want customized functions or classes, you can just create them on the fly, I would think. Even more so for languages like Lisp. I wonder if there are any situations where code generation (from, say, Python to Python) would actually be necessary, or at least a significantly better solution than generating functions/classes/etc dynamically.
I don't see why you should except Python generating modules from code generation. In J2EE, the application server generates Java code from JSP pages. With Cheetah, nearly the exact same thing happens.
In both cases, the code is enormously hard to understand or debug, and deep down I can't help but feel that it's wrong.
I know of Common Lisp "lisp markup languages" for web pages that use macros, or at least generate s-exps - that seems better, but on a higher level, really isn't very different.
I like what PTL from Quixote does (Actually, I don't like it enough to use it ... but architecturally). It manipulates the AST directly, to allow any string expression that isn't assigned to a variable or used as a parameter to a function to accumulate.
It's like having "data.append(" and ")" wrapped about every line, and a hidden "return ''.join(data)" at the end - all without writing "code" as such.
I do a fair amount of code generation *with* Python.
CherryPy is another example of code generation. Whether it's good or bad is another question.
The only place where I see any possible use for code genration is in parser generators(yes, I know about pyparse, and it's _hideous_).
Cheetah is an abomination that should die, the only thing I miss from the Java world in python is Velocity, which unlike cheetah, is interpreted and doesn't need code generation hacks.
Cheetah feels like going back to JSP except for a slightly better syntax.
I agree completely that code generation is a bad excuse for flawed languages.
"Cheetah is an abomination that should die, the only thing I miss from the Java world in python is Velocity, which unlike cheetah, is interpreted and doesn't need code generation hacks."
Many of the PHP template engines (e.g. Smarty and WACT) "compile" templates which, in practice, means parsing some template language and generating a PHP script for future executions. The main reason for doing so is performance - parsing and interpreting on every request can add a significant overhead but a template will only change occassionally.
Surpisingly have yet to see Python used to generate PHP. Given PHP's ease of deployment on a web server and Python's sanity as a development tool, might make a good combination - convert a well abstract Python design into a fast, unabstracted PHP form for execution.
There's more at http://www.codegeneration.net/
Aha! Well, it's nice to be a pioneer - I have just completed a system for functional and regression testing of web applications which relies upon the powerful combination of Python and PHP. Unfortunately it's closed source (I'm suffering the agony of not owning the intellectual property I've spent two months of 12 hour days developing!) and will be unlikely to get a commercial release as it's a bespoke tool for my employer (but who knows) but I will describe the concepts:
A wxPython app combines a Proxy Server with a visio-style canvas view. Browse the web through the proxy, and each request shows up as an object in the diagram. Select an object and a properties-inspector style grid at the bottom of the page lets you set get and post variables for the request, set assertions to be performed (eg Http response code is not 404) and so on.
By double clicking on the request objects, the user builds up a Test script on a second visio-style canvas; this can use requests recently recorded or old ones stored in a library.
Once the test script is built up (in visual form - this is designed for non-development QA staff) click a toolbar button and the real magic happens: a cheetahtemplate implementation converts the in-memory python objects representing the http requests into...
...a PHP script. This plugs into a fairly complex test running and logging framework. Tests can then be run on a schedule or at will.
So... I'm using Python to generate PHP, and it works, and it's seriously cool, and I just wish I owned it. But I guess (software patents not *yet* withstanding) I can reuse the *concept* and reimplement it all myself... if I want to wander into that great conflict-of-interest minefield. Oh well.
For what it's worth, Cheetah can be very useful in some settings without using any of it's code generation abilities. I've got a few scripts which monitor data and re-create static HTML pages using code like this:
def createFile(templateFile, settings, filename):
"""Convenience function to fill in Cheetah templates"""
templateObj = Template(file=templateFile,
file = open(filename, 'w')
Does Cheetah generate Python code?
Hans: Yes, it does. You can use cheetah-compile and it will make a library suitable for importing, but IIRC, if you use a Template object programatically, it just writes the code and eval()s it.