I am finding that as my project evolves, I ditch progressively more pieces of web.py. I ignored the form processing library and custom template library from the start, because plain old web.input() and Cheetah are fine for my uses. I ditched the DB library after a month or so - a single global DB connection prevented us from unit testing, and will prevent us from replicating or sharding the database. I'll probably ditch web.py's interface to Cheetah in the near future in favor of precompiled templates (necessary for i18n), at which point I'll just be using the request dispatching features. May end up ditching those too eventually as we've got our own dispatcher on top of web.py, but for now it provides a useful substrate.
That's the main benefit to web.py: it lets you get up-and-running very quickly, with little extra code to weigh you down, so you can see your startup running and adjust from there. It's basically a prototyping tool.
IMHO, startups should not be using any framework. The whole point of a framework is to abstract away common usage patterns so you can benefit from what other projects have done before. The whole point of a startup is to do something new that hasn't been done before. Once a problem domain has been studied enough to build a useful framework, it's too commodified to make any money off of. After all, if it was easy for you to build, it'll be easy for a thousand other startups to build.
So you're saying that since web.py fails to provide a solution to common problems, it gives "real developers" the freedom to implement it themselves? Pesky frameworks like django only allow the same developers to jump straight to doing new things. Uh, that must be the pre-defined ultra-boring pattern.
Yes, correct on the second part also.
your innovation as a startup will not be reinventing wheels -- building and debugging frameworks that, fortunately for you, others have put [tens of? hundreds of?] thousands of man hours into, solving seriously unsexy problems like browser incompatibilities, security nits and writing init scripts. i can't see how it's faster to tackle all of these things _and_ your application code than just, um, building your application code leveraging one of the very solid foundations that already exist.
while your competitors are solving problems that matter to your users, you'll be running around feverishly putting out fires when someone types an é into your application, or starts getting funny with strings involving apostrophes, semicolons and "drop table", or script tags in comments.
A larger, more complex framework does present serious problems when you have to architecture everything in strange ways to meet scaling needs or otherwise.
Note how much the twitter guys were so scared by ROR's complexity that they resisted doing the most trivial modifications? I want to understand my framework "all the way down." This is much the same reason I use linux.
I see libraries solving these problems. I use Cheetah too, and am grateful for its #filter Websafe. I use Markdown - it has the same javascript: bug as Reddit, but at least I or someone else can submit a patch to Markdown and have it fix every site using Markdown and not just my own. I use the parameter replacement available within DBAPI to avoid SQL injection attacks.
I don't like software that tries to solve all my problems, because it inevitably mis-guesses and solves about 80% of them, making the remaining 20% pretty hard in the process. I like software that tries to solve one of my problems and solve it well, because then I can swap in the best solution for the job. Fortunately, the newer Python frameworks (Pylons?) are going down that road, but I didn't see much advantage in using Pylons over using DBAPI + Cheetah + Prototype + Web.py dispatching.
not to sound overly harsh, but web.py seems like a big case of NIH. each of its pieces seem like v0.1s of more established counterparts. mature web frameworks are occasionally big and ugly _because_ they work around that random safari bug from 2002 or the flash 8 player's uploader non-RFC-compliant MIME-multipart requests and all the unicode encoding and DB integration nits, etc. the plumbing looks gross because the surface area of the problem they solve is gross.
and with the big frameworks, thankfully hordes of others have banged their heads against and solved these issues; with a "lighter" framework, or one of the 4328429 me-too python web frameworks from 2001-2004 that didn't really make the cut, you're volunteering to blunder into and track down all these problems yourself over the next year or two -- probably not the best use of your time or problem solving skills.
Good third-party components should solve a problem with a large surface area and present an interface with a small surface area. I don't really see that with most frameworks: instead, they seem to solve a problem with a fairly small surface area and present an interface with a large surface area. Not really a great combination.
I'm all for libraries and standards, though. There's no way I could've built my app without Cheetah, PIL (despite installation headaches), Markdown, DBAPI, and WSGI. These solve the real hairy problems, yet provide a small, often trivial interface to learn.
We like web.py for its minimalism. It means we did have to write a database layer for it, but we still feel it was better than using Django as we've got more control. This app's big enough that we want it to run the way we want it to -- web.py lets us do that. And when it doesn't, it's small enough to hack.
As for docs, web.py's size means that the limited docs it does have are pretty much enough. When they haven't quite been, we've found the web.py group pretty helpful: http://groups.google.com/group/webpy/
That being said, the documentation is a very large problem. When I run across issues and the documentation isn't there, it can be difficult to get a quick answer. There's a wiki of the documentation, but it has very few contributors.
I think the general problem is that the community is very split in terms of experience, with little intermediate discussion. The typical questions on the webpy board are either really basic ("how do i get started") or discussions about the project's direction. I don't think typical programmers are discouraged from participating, but there isn't enough "average" programming level discussion to make it feel like a community.
Just my 2 cents.
The sooner you switch over to Django, the better and easier your life will be.
We've built http://www.barcoderobot.com using it ...
http://groups.google.com/group/webpy/browse_frm/thread/2fcbcb60a99a1c79/
Aaron's mistake is at post #4, my response is post #5.
Yeah, that's from a while ago. That's about when I stopped using web.py, too.
\But\ from the beginning, everyone using webpy has seem to know flup sessions to be the recommended way of doing sessions:
http://webpy.org/track/wiki/SessionsWithFlup
Let's look at this another way though. If you really need security, then which is better: a simple, quickly verifiable codebase like webpy, or a massive, magical code base like django and turbogears? Do any frameworks make any guarentees of security?
I have seen several high profile sites within the last two years with major, obvious security problems. As hard as this is to believe, I no longer think that security is what will determine the success of most any web app -- at all. Unless you have special needs, feelings of security should not be your primary metric in evaluating a framework.
http://www.daltonlp.com/blog_my
And a bunch of small one-off things.
I like it. It's not perfect - the templating system in particular is not as nice as what it aims to replace (cheetah & kid). Yet.
For all the complaining about NIH, web.py has done a pretty good job of playing nice with other layers in the web stack (fcgi/flup, cheetah/kid). The parts that are reinvented have been reinvented in quite different (and better) ways than other frameworks. i.e. Request dispatching and DB interaction.
I highly recommend webpy.
edit: downvote?
switched to django