You don't have to use it -- each part of web.py is completely separate
from the others. But you're right, it is "yet another template
language". And I'm not going to apologize for it.
The goal of web.py is to build the ideal way to make web apps. If
reinventing old things with only small differences were necessary to
achieve this goal, I would defend reinventing them. The difference
between the ideal way and the almost-ideal way is, as Mark Twain
suggested, the difference between the lighting and the lightning bug.
But these aren't just small differences. Instead of exposing Python
objects, web.py allows you to build HTTP responses. Instead of trying
to make the database look like an object, web.py makes the database
easier to use. And instead of coming up with yet another way to write
HTML, the web.py template system tries to bring Python into HTML. Not
many other people are really trying to do that.
You can disagree that these ways are better and say why. But simply
criticizing them for being different is a waste of time. Yes, they are
different. That's the whole point.
"There should be one-- and preferably only one --obvious way to do it."
- >>> import this
The problem is that we still don't have one obvious way to build web
applications in Python -- and we may never. But the proliferation of
(often, barely indistinguishable) options makes life harder for the
I don't think you're doing the wrong thing, here. I like web.py a lot,
though I'd like to see the db stuff be separated from dispatch. We all
have our own ideas. I'm just trying to get a handle on the objections,
and I think the general character is that we're in TMTOWTDI land.
That ship has probably already sailed, unless there's a serious effort
to coalesce the different web frameworks or try to make one that can
be blessed, which I don't think is going happen barring Guido's
I do find some irony in the fact that Ruby, the Perl-alike language has
One Obvious Way To Do It, and Python doesn't, but oh well. Worse things
Seriously, I don't think you actually need to defend the (API) design
decisions that much... simplicity, modularity, and such. And, as far as
I can understand, many of the other other frameworks seem to be
targeting something a bit more higher level, anyhow.
Twisted is a nice exception, even if it is something completely
different. But maybe worth remembering still.
When I first used django i was suprised of how simple this can be. And
how fast. Two of my projects work very good on django and i won't
Then I started a project which should be easy to distribute. I said to
myself: "Hey. django is cool but not that portable. Have a look at
And I had a look at WSGI and then at web.py
web.py is quite nice. But in my mind a bit too magic. And the code was
(now improved) unreadable in my mind. I tried a bit but then I created
colubrid, which only implements a request object with access to
GET/POST vars, COOKIES and file uploads and a url dispatcher. Currently
I'm quite happy with it.
Why I'm still interested in web.py? Because it's the first php like
wsgi implementation which is very good for small projects like personal
webpages and so on.
My wishlist: remove some magic, create trunk/tags/branches folders in
the svn repo, and add documentation.
Additional informations to simplify python on the web: mod_wsgi ^^
IMO, the docs are critically important.
With great docs, anyone can understand, use, and even improve the
code on their own. Without great docs, you'll get endless newsgroup
postings, frustrated users, and minimal code contributions.
Another note about good docs: From what I can tell, in general, it's
exceedingly easy for talented and prolific developers to fall into the
trap of writing docs with the mindset that others already understand
what the original developer understands. Luckily, if the tutorial is
good, at least folks can get started with complaining about which parts
of it they're having trouble with. :)
(Personally, I'm trying to make some time to work through the tut, but
work is extremely busy this week.)