in defense of reinvention, or, the goal of web.py
Aaron Swartz
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.
David Terrell
> 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
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.
Tommi
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.
Armin Ronacher
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 ^^
john_s...@yahoo.com
> the svn repo, and add documentation.
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
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.)
li yusen
在 2006年2月23日星期四UTC+8下午10时59分26秒，Aaron Swartz写道：
NSC
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.
