Pythonic way of web-programming

Paul Boddie paul at boddie.net
Tue Apr 15 06:24:12 EDT 2003


Andy Robinson <andy at reportlab.com> wrote in message news:<d5mm9v8em9j41kus2tvj2raipd7dagv18k at 4ax.com>...
> 

[Super-frameworks]

> I think it's sad that Python has this slogan "there's only one way
> to do it", but that nowhere is this less true than web development.
> At Python-UK I opined that this might be holding us back in comparison
> to other languages and tools.  Anyone coming into Java or .NET
> development gets a very clear feeling of "one way to do it".

At the lowest level, Java (and presumably .NET) does indeed have one
strongly standardised way of doing things, and there's little point in
people going against the flow at that level, especially since most
people don't do a lot of work at that level when writing their
applications. However, the same could almost be true for Python: many
frameworks seem to adopt a request/response style and reuse parts of
the CGI implementation, although it's true that not all frameworks
expose request data in similar ways.

It's also worth noting that whilst the Java platform has various
favoured frameworks for Web programming, the "framework space" is
arguably as fragmented as it is for Python. Choose your framework from
"straight JSP", Struts, Cocoon, Turbine, Expresso... (See
http://www.waferproject.org/index.html for a long list.) The
consequence of all this is that Java development projects can tend to
play it safe and select a fairly low common denominator requiring lots
of tedious legwork and wheel reinvention.

> We have a bunch of competing frameworks, but if we analyze them
> into layers then they compete less, and a more compatible approach
> must be possible.
> 
> First, let's note the half-a-dozen different templating schemes
> available.  DTML, Woven, Quixote, YAPTU, preppy.

Modularisation at the templating level is essential for generic
frameworks. Thus, I find hard-wired Python-in-HTML solutions
uninteresting.

[...]

> Wouldn't it be nice if one day we could have some standardized
> interfaces, so that one could switch between these without undue pain
> and reduce the confusion people must face?

Indeed.

Paul




More information about the Python-list mailing list