web.py never really worked well, so we ended up rewriting it again. The interesting thing was that Django still wasn't up to the task when we did that, mostly because it's templating engine was too slow. So we chose Pylons instead.<p>It should be noted that Django has since fixed that issue.
For all people still thinking that Django is not "lean" or flexible enough for their next project, let me just leave this here: <a href="https://speakerdeck.com/mstepniowski/django-best-python-micro-web-framework" rel="nofollow">https://speakerdeck.com/mstepniowski/django-best-python-micr...</a><p>A single-file web application in Django: <a href="https://github.com/mstepniowski/microdjango/blob/master/polls.py" rel="nofollow">https://github.com/mstepniowski/microdjango/blob/master/poll...</a>
The first Python web framework I used was Django. I'm really glad I came across it first because I was inexperienced at the time and it forced me to adopt a lot of good practices.<p>However, now that I'm more experienced, I can relate a little to what Aaron is saying here. Learning all of this boilerplate stuff is annoying! Recently, I started contributing to a friend's rails app and I found the process of learning how to use each separate little tool tiresome.<p>This is why I like Pyramid - it starts off dirt simple. Hello World is almost as short in Pyramid as it is in Flask. As you grow, you can start organizing and adding different things as you need them. It has absolutely 0 magic. I find Pyramid to be a happy medium between Flask's minimalism and Django's extensibility.
><i>The Lisp newsgroup, comp.lang.lisp, was upset about the switch that they’re currently planning to write a competitor to reddit in Lisp, to show how right they are or something.</i><p>That must have ended as a huge success, because as we all know the important thing behind a website is the backend language...
Note that reddit has rewritten at least once since the web.py rewrite. cf. <a href="https://news.ycombinator.com/item?id=51078" rel="nofollow">https://news.ycombinator.com/item?id=51078</a><p>I recall reading a more scathing post from spez at one point about frustrations with web.py, but I don't seem to see it now. It may have been removed. In any case, Flask seems to be the inheritor of the "write webapps in Python" description.
web.py is still my go to for lightweight webapps. I won't start a big discourse on the pros and cons vs. other technologies, but I will say it is incredibly easy to setup and use.<p>The current github page is here: <a href="https://github.com/webpy/webpy" rel="nofollow">https://github.com/webpy/webpy</a><p>If you are looking to get up and running quickly, I would recommend forking this skeleton: <a href="https://github.com/jzellman/webpy-skeleton" rel="nofollow">https://github.com/jzellman/webpy-skeleton</a><p>Finally, the built in database framework is a bit simplistic. I like to pair this with Peewee (included in the webpy-skeleton).
Used Tornado, django and flask quite a bit, web.py only once. As others have mentioned, it didn't work that well, and the community around it is smaller than other frameworks. Again today, Django seems a bit cumbersome, Tornado works well but has a very low bus factor.<p>Pretty sure flask is currently the front runner in "python microframeworks".
For another take on the Reddit rewrite from Steve Huffman see:<p><a href="http://www.pyvideo.org/video/234/pycon-2009--keynote--reddit--steve-huffman-and-al" rel="nofollow">http://www.pyvideo.org/video/234/pycon-2009--keynote--reddit...</a><p>25m 40s
We currently use web.py + gevent to run our API where I work. It's really easy to work with since it's so tiny and simple, and since we only need JSON in and out for now, it's perfectly sufficient.<p>Before web.py, we were on a scary Tornado implementation. The API was rewritten to web.py in a week with a minimal delta. We won't be on web.py forever, and gevent sometimes kicks up minor fusses, but I think web.py has given us a nice malleable form that helped us get out of a terrible place, and we can easily hop off once we decide where we want to be.<p>RIP aaronsw.
I've used CherryPy on a number of projects, and I really like it, but rarely see it mentioned in discussions of Python web programming. It's light and minimal, and seems equally deft for writing APIs as conventional web page driven apps. Flask is mentioned all the time, however. Does anyone have insight into the popularity of Flask vs. CherryPy?
I think you can leverage these criticisms at about 90% of the framework software out there written in just about any language. Most developers like to create complex, complicated software mainly to show off their "cleverness" without thinking through the implications for the people that have to use it. It's as if they think that by cramming in every design pattern they can think of and using many different libraries together for no perceptible reason makes the software better when they could've achieved the same thing much more simply and cleanly if they had put a little thought into it. Such over-engineering is equally a problem as the spaghetti code of programmers who don't know better.
Just wondering (as someone who only uses/touches Python indirectly, through some projects that use it, but is not currently a 'Python developer' by any means); was this posted in response to some recent drama in the Django community, or as an argument against Lisp?<p>I'm just wondering why it seems this story is quickly getting upvoted on the front page of HN, when it seems there are no other frontpage stories remotely related to Django, Reddit, or Lisp?
> "It means readable HTML with the proper HTTP headers."<p>said all the other frameworks's authors a few months before him that are now churning out deprecated headers just like that one will in a couple months, while gallantly trying to protect the user from handling headers.