[mod_python] Pattern Based Frameworks

Graham Dumpleton grahamd at dscpl.com.au
Tue Jan 10 22:35:23 EST 2006

Your requirements are a bit confusing. I've made a few comments
below, but before I get into an indepth discussion, how much do
you really know about mod_python, or are you relatively new to it?
Knowing this would help me in knowing where to pitch and further
detailed response.

Richard Smith wrote ..
> Hey guys and gals,
> I'm doing some research into open source pattern based frameworks for
> Mod_Python...
> Now the reason I'm posting to this list and not googling is quite simple.
> The frameworks have to adhere to the following 3 rules:
> No bloat: No unneccessary libraries/modules/support. Just a simple pattern
> based request handler architecture.

Careful not to confuse large with bloat. Something can be large but
still well coded performance wise. It just may be that it has a large
feature set.

> No dependancy on any specific components: so Cheetah/CherryPy/Quixiote
> et al

Not sure why you may have bundled Cheetah in there as it sits quite
distinct from CherryPy and Quixiote. With Cheetah, it is basically just
a template system. It can be used on a number of other lower level
dispatchers. CherryPy and Quixiote are primarly dispatchers. That
CherryPy can sit on top of mod_python doesn't really matter, as it
pretty well ignores what URL mapping might be performed by Apache and
does the URL interpretation and dispatching itself. Ie., CherryPy really
just uses mod_python as a jump off point and doesn't really make use
of much of mod_python at all. Ie., doesn't use mod_python sessions,
form processing etc etc.

> Pure mod_python: the framework was built to work on mod_python alone. Any
> subsequent contributions that allow it to work on other execution models
> but
> are not a core part of the source are allowed.

This would again be where something like CherryPy doesn't qualify. The fact that
it does everything itself means it could quite as easily host of WSGI. Cheetah
doesn't really care what it is used with so isn't ruled out by this requirement.

Note, I am not pushing Cheetah over other systems, but just pointing out
that not sure why you have disqualified it already.

> Must be pattern based (Observer, singleton, MVC etc)

Pattern is such a general and misused term even if you quote examples. You
may want to provide more of a description of what you are hoping for.

> Must use realtime rendering of templates rather than a pre-compiled template.

Any specific reason why? The only problem with pre-compiled templates
is that systems that use them often don't implement a way of performing
on the fly reloading of template code when it changes on disk. Mod_python
has automatic module reloading which can help with that if the templating
system understands it to a degree, but for that to work properly will still
necessitate mod_python's automatic module reloading to be fixed as it is
currently broken in various way. A new implementation is basically ready
for experimenting with once mod_python 3.2 final is out of the way.

> I know this is a fairly tall order on the stakes of things, and hence why
> I've had considerable difficulty in locating such frameworks.
> I'd love to discuss onlist what people think of the various frameworks
> available.

Happy to have a discussion, but rather than just give a list of frameworks,
would rather more understand the style of how you want to work and how close
an association with mod_python you really want.

Hope it doesn't sound like I am being too difficult.


More information about the Mod_python mailing list