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.

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
Pythoneer.

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
involvement.

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
have happened.

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
change.

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
WSGI."
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 ^^

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
pretty
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.)

I DO AGREE, haha, too late.

在 2006年2月23日星期四UTC+8下午10时59分26秒，Aaron Swartz写道：

For my part, I'm a true fan of web.py.  I've used most of the options out
there at least once, from ASP.NET to Django to Rails.  Each has a purpose,
some (Rails) were just too damn complicated for me personally to get my
head around and others (.NET) just don't make it easy for you to do thing
any way other than the (well documented yet often inefficient) way.

All these options out there work well for what I'll call a "moderately
basic" web application, but fall short when things (inevitably) get
complicated.  We've all at least once spend days trying to jump some hurdle
because our application is just "special" and our toolkit just doesn't
quite fit.

For example: I don't wanna be forced to abstract my database into objects
and compartmentalize my code into MVC. (I like sql, and am good at it.)  I
don't wanna have four technologies (html/css/js/php) intertwined all in one
file.  I don't want to compile all my code every time I change one line
just to test it.

Some of my objects actually have sub-classes six levels deep.  Most of my
objects have at least a dozen methods, can be queried for presentation in
multiple ways (list, edit dialog, draggable item, etc), and can deliver
themselves in dictionary, json or xml format.

Web.py empowered me to start working immediately, without having to mess
around with any of the HTTP crap.  Since my pages are well more complicated
than tables, buttons and forms, I've not used the templating bit.  Because
I already had a solid database layer (and my application connects to
multiple databases defined customly at runtime) I could not use the built
in db layer.

My point?  In my opinion, web.py fulfills and stays true to it's mantra.  I
rebuilt an enterprise application from the ground up in python in 10 weeks,
by simply "thinking about the ideal way to write it" then making it
happen.  Every other tool I looked at was a barrier - web.py was an enabler.

For me.  Your mileage may vary.

NSC

P.S. As others have said... yes, I do agree when getting started the
documentation was kindof annoying.  I think the community here would
deliver some great, practical tutorials if a wiki were started and opened
up for contribution.  I'll write at least two.

Isn't a wiki a good idea??