does web.py have documentation and are you using webpy?

I'm using web.py. I really didn't want something like Django or even Pylons where it feels like you're programming <i>to</i> the framework and not to the language. In my experience (with other frameworks), this leads to a really quick 80%, and then you get really screwed over as you try to complete the remaining 20% and have to fight the framework all the way.<p>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.<p>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 <i>see</i> your startup running and adjust from there. It's basically a prototyping tool. <p>IMHO, startups should not be using <i>any</i> 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 <i>new</i> 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.

looks like web.py has some interesting ideas and useful data munging functions. but unless there's something i'm really missing, most normal web apps (that aren't completely trivial) are way better off using turbogears or django, which provide mature and usable components (templating, object-relational mapper/query building/db access, web/WSGI server). i've built a couple reasonably large web apps using turbogears and love it (although i use cheetah instead of kid) and django seems to be winning the python framework race.<p>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.<p>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.

A timely post ... we're just about to release a biggish site running on web.py. Check out our blog, which I just released today: <a href="http://blog.micropledge.com/" rel="nofollow">http://blog.micropledge.com/</a><p>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.<p>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: <a href="http://groups.google.com/group/webpy/" rel="nofollow">http://groups.google.com/group/webpy/</a>

I'm currently working on a largish project using webpy (well, large for one person). In terms of getting started an barriers to entry, it's very easy to use and getting results is a breeze. <p>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. <p>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.<p>Just my 2 cents.

I wasted 2 weeks on web.py. Why a waste? No documentation and you outgrow it VERY quickly. As soon as you realize you need a feature (e.g. caching), you'll have to implement it yourself. <p>The sooner you switch over to Django, the better and easier your life will be.

<a href="http://webpy.infogami.com/docs" rel="nofollow">http://webpy.infogami.com/docs</a> - documentation <a href="http://groups.google.com/group/webpy?lnk=oa" rel="nofollow">http://groups.google.com/group/webpy?lnk=oa</a> - Discussion Group<p>We've built <a href="http://www.barcoderobot.com" rel="nofollow">http://www.barcoderobot.com</a> using it ...

No, I'm not using web.py. I started out using it and switched to Pylons, because web.py was too simplistic for my needs, and because a nasty security gaffe Aaron made eliminated my trust in his ability to write secure code.

I've been pretty happy with web.py for two web apps:<p><a href="http://www.colr.org" rel="nofollow">http://www.colr.org</a><p><a href="http://www.daltonlp.com/blog_my" rel="nofollow">http://www.daltonlp.com/blog_my</a><p>And a bunch of small one-off things.<p>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.<p>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.<p>

People seem to really dislike frameworks and I know they can be more trouble then they are worth at times but I really like TurboGears. It's python based, sits on top of CherryPy (webserver) and you can take as much or as little as you need. It has a great philosophy of pulling in all thats good from all over the python world and loosely coupling it together in to a framework. It's not perfect by an means but it's a lot better then inventing that wheel again!

No and Yes. I am thinking of releasing tons of code for it though as soon as I wrap up the large project I'm working on.<p>I highly recommend webpy.<p>edit: downvote?

Thanks folks for your thoughts..

no.<p>switched to django

It will be interesting to see if web.py jumps on the facebook apps bandwagon before its competitors Rails, Drupal or Cheetah. Is Aron the next Zuck?