

Python Web Frameworks – Development Server - dabent
http://pyrseas.wordpress.com/2011/12/29/python-web-frameworks-development-server/

======
nas
FYI, Quixote (<http://quixote.ca>) provides a bunch of options too:

    
    
         python -m quixote.server.simple_server
         python -m quixote.server.medusa_server
         python -m quixote.server.twisted_server
         python -m quixote.server.fastcgi_server
         python -m quixote.server.scgi_server
    

simple_server uses BaseHTTPServer and is thus single-threaded and blocking but
works fine for development. I like FastCGI or SCGI with a dedicated webserver
as a frontend for production.

------
bwooceli
(posted to blog as well) would like to know more about the
strengths/weaknesses of these development resources. For example, one of the
things i love about the django dev server is that it "listens" to all the
project dependencies and restarts when any file is saved (which has saved me
from trying to understand why something I fixed didn't work and discovering
that it's because the changes weren't .pyc'd)

~~~
chrisguitarguy
Flask/Werkzeug does that as well, provided your app is in debug mode.

For flask it's...

    
    
        app.run(debug=True)
    

Or having `DEBUG = True` somewhere in your config object/file.

~~~
prolepunk
One thing about that though, Flask seems to monitor file changes in its
project tree and reload whenever any of the files have changed, and with my
OCD symptom of saving after every few dosen keystrokes, the reload script keps
crashing on syntax errors taking the rest of the server with it.

------
perfunctory
That's not a bad overview, but what's the point? How one way is better than
the other? Does it make any difference which development server to use?

~~~
prolepunk
Although it's not stated, the point is that pretty much every framework that
is not based on Twisted uses BaseHTTPServer which is known only to run in
single-process mode, meaning that you should NEVER use it anywhere near
production environment.

~~~
BarkMore
I am not sure what you mean by "single-process mode", but I am guessing that
you are referring to the ability to serve more than one request at a time. If
this is the issue, then BaseHTTPServer works just fine in production
environments if a thread pool is used or if multiple instances of the
application are run behind a reverse proxy.

~~~
prolepunk
Sorry I wasn't clear, I meant serving more than one request at a time, and
apparently this is even possible without using multiple instances, use
multiple inheritance with a threading mixin. This is not going to be properly
concurent due to GIL limitations but it should be good enough --
[http://blog.doughellmann.com/2007/12/pymotw-
basehttpserver.h...](http://blog.doughellmann.com/2007/12/pymotw-
basehttpserver.html)

However this setup can lead to socket lockup (see picked answer) --
[http://stackoverflow.com/questions/5693741/whats-
difference-...](http://stackoverflow.com/questions/5693741/whats-difference-
between-a-simple-webserver-and-apache-server)

~~~
BarkMore
I am not sure what you mean by "properly concurrent", but I am guessing that
you are referring to the fact that Python code cannot use more than one core
because of the GIL. This limitation also applies to Twisted applications.

For high volume apps, it often makes sense to run multiple instances of the
app behind a reverse proxy. That's the only way to make full use the CPU when
running Python.

What is "socket lockup"? The word "lockup" is nowhere to be found on the page
you references.

------
jtchang
Sometimes I have problems with runserver and IE. I forgot exactly why
(probably multiple requests) but fixed it by using this:

<https://github.com/ashchristopher/django-concurrent-server>

Really nice module.

------
jamesgeck0
The twisted.web server is nice because you can both develop on it and deploy
it with minimal configuration. Using twisted.web.wsgi.WSGIResource, you can
use it to serve normal WSGI sites, too. It's handy for running multiple sites
on different ports.

It doesn't automatically reload on file changes, but PyQuitter[1] can provide
that functionality, so it's not a huge issue.

1\. <https://github.com/ludios/Pyquitter>

------
danko
What this article taught me is the mind-boggling plethora of Python web
frameworks out there. I'm heavily into Django myself, and it does well enough
that I'm curious as to the demand for the other frameworks. How many Python
web frameworks do you really need in 2012?

~~~
samlev
For me? Two.

Django is good for getting a site/system up and running fast, so long as I'm
not too concerned with specific implementation details (the users 'just work',
etc.)

Pyramid is good for a longer-term/more custom system where being easily able
to modify (or choose) particular implementation details is important to me.
It's not as fast to get a full-featured site off the ground, but the pieces
glue together in a way that I really like.

I think that there was a well known post many years ago about "glue" and "full
stack" frameworks, comparing pylons (now pyramid) as the former, and django as
the latter.

#EDIT: Oh, and I used to do a bit of work with Zope/Plone, but that's pretty
much what you'd consider to be the 'enterprisey' setup for python, and I
wouldn't recommend it for most uses.

~~~
inovica
That mirrors exactly our experience. We have used Pyramid for three recent
project and its awesome. It just takes a little longer, but its flexibility is
impressive. We've just used it with Pure templates also, which I was very
impressed with

