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

======
nostrademons
I'm using web.py. I really didn't want something like Django or even Pylons
where it feels like you're programming _to_ 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.

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.

~~~
dhouston
you lost me with that last paragraph, to put it nicely.

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.

~~~
timg
Can you explain to me how unsexy problems like browser incompatibilities (yes
a major pain) lie anywhere within the scope of webpy? Those seem to lie within
the scope of the templating system and js library that you choose.

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.

~~~
steve
Parent has important questions that should be addressed, or is this is just a
django vs the world flamewar?

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

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.

~~~
nostrademons
There's value in using a v0.1. It hasn't had a chance to get large and
complicated yet, so it's easier to learn and less likely to break.

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.

------
benhoyt
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:
<http://blog.micropledge.com/>

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/>

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

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.

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

The sooner you switch over to Django, the better and easier your life will be.

------
chexov
<http://webpy.infogami.com/docs> \- documentation
<http://groups.google.com/group/webpy?lnk=oa> \- Discussion Group

We've built <http://www.barcoderobot.com> using it ...

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

~~~
timg
That security gaffe was in Markdown - a piece of junk that I've been pointing
out flaws in for the past year.

~~~
inklesspen
That's not the security gaffe I'm talking about.

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

~~~
timg
Yes, I understand your concern. For sure, aaron was on drugs when he mentioned
this quick, non-secure fix -- even though the asker most definitely had very
loose security requirements given that he was using nothing more than CGI.

\ _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.

~~~
inklesspen
Luckily I don't use a massive, magical code base like Django or TurboGears. I
use Pylons, which is small enough that you can understand it all, large enough
that you can actually do useful things with it, and written by some very smart
people.

------
daltonlp
I've been pretty happy with web.py for two web apps:

<http://www.colr.org>

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

------
dazzawazza
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!

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

I highly recommend webpy.

edit: downvote?

------
Keios
Thanks folks for your thoughts..

------
rnc000
no.

switched to django

------
googvsfacebook
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?

