

Ask YC: Your opinion on webpy for web programming - aitoehigie

I am new in web programming using python and i will like to have this forums take on webpy. i know python and i find webpy to be light on the brain, but i dont know if it can handle a digg effect. please advice.
======
cstejerean
I'd say the spectrum of Python web frameworks looks like this

web2py -> Django -> Turbo Gears -> Pylons -> Web.py

On the left you have more fully integrated frameworks that do more out of the
box (and essentially make more choices for you upfront). On the right you have
frameworks where you do most of the work yourself. These frameworks eliminate
some of the boiler plate of writing a web applications and give you the
responsibility of handling the rest.

Which one to use depends on what you're looking for.

There is no reason any of the above frameworks can't handle a "digg effect".
Just throw servers at it.

~~~
dazzawazza
I'd agree with the graph you've drawn there. I'm a big fan of TurboGears.

The reason I chose it was because it sits in the middle. It does a lot of
stuff for you... but you can get rid of most of it when you need to.

Looking at web.py I think you'll suffer from the poor docs and the code can
get a little hairy.

As a simple web server you may want to check cherrypy (which under pins
TurboGears). It's got a good reputation, good docs and can be deployed in a
variety of ways behind apache (or many other web servers)

~~~
mdipierro
This funny because when web2py started we aimed at being small like web.py. In
fact the core web2py functionalities (from gluon import *) are very similar to
web.py and the entire core is less the 120KB. Ocan still use it that low level
and import SQLAlchemy and Mako for example (with loss of some of the higher
level functionalities of course, like the database administrative interface).

Anyway, I agree with Cosmin's assessment that it grew to do a lot more. The
main phylosophy is that the framework should make (by default) some decisions
for the user, in particular particular about things that have to do with
security and persistance.

At high level web2py borrowed some ideas from Django (the administrative
interface and {{...}} in templates), some from Turbogears (response.flash?)
and some from cherrypy (@cache).

------
mronge
I too was initially drawn to web.py because of it's simplicity, but now that
I'm using Django, I can't recommend web.py anymore. Web.py isn't as well
documented, and once you get beyond a very trivial site Django enhanced
functionality really helps out.

I suggest going with Django. There is a little more upfront learning, but it's
worth it.

------
ivankirigin
I found Django easier to use with better support from the community and
documentation.

I wouldn't worry about the digg effect. Worry about making something good --
which means making anything as fast as possible and asking people what they
really want.

------
daltonlp
I run <http://www.colr.org>, which is powered by web.py. It has survived
several digg / lifehacker / other high-traffic incidents.

If you are running web.py as a fcgi process, you'll handle a digg effect just
fine.

If not, you'll peg the server and your site will be largely unavailable.

Happily, switching web.py from fcgi to non-fcgi mode or back again is a
single-line change :)

------
dedalus
For me flexibility was important and web.py just let me do my stuff without
getting in the way while being minimal. Of course I wrote my app on web.py +
Medusa (<http://www.amk.ca/python/code/medusa.html>) and old but extremely
cool for me to scale for my needs

------
inklesspen
I really love Pylons; if you want the "no unneeded cruft" philosophy of
web.py, but want a widely-used framework, you may like it too. It's what
Reddit switched to.

~~~
jamongkad
Upvoted for the use of Pylons.

------
marcus
Don't worry about surviving the digg effect just add memcache, worry about
building the application rapidly, cleanly and being comfortable with the
codebase.

