5 ms·

Ask YC: Your opinion on webpy for web programming

7 points by aitoehigie 19y ago

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.

ivankirigin 19y ago
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.
cstejerean 19y ago
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 19y ago
  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 19y ago
    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 19y ago
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.
inklesspen 19y ago
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 19y ago
  Upvoted for the use of Pylons.
marcus 19y ago
Don't worry about surviving the digg effect just add memcache, worry about building the application rapidly, cleanly and being comfortable with the codebase.
dedalus 19y ago
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 http://www.amk.ca/python/code/medusa.html) and old but extremely cool for me to scale for my needs
daltonlp 19y ago
I run http://www.colr.org 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 :)

7 points by aitoehigie 19y ago

ivankirigin 19y ago

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.

cstejerean 19y ago

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 19y ago
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 19y ago
  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 19y ago

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.

inklesspen 19y ago

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 19y ago
Upvoted for the use of Pylons.

marcus 19y ago

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

dedalus 19y ago

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 http://www.amk.ca/python/code/medusa.html) and old but extremely cool for me to scale for my needs

daltonlp 19y ago

I run http://www.colr.org 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 :)