We Keep Coding

My first web app (Python): use CGI, or a framework like Django?

I don’t want to burden you all with the details, but basically I’m a 2nd year compsci student with no Web dev experience.
Basically I want to create a small “web app” that takes in input from a html form, have a python script perform some calculations, and re-display those results in your browser.
As of right now, I have the form and script built. However, when I try to test the form, instead of running the script, my browser tries to download it. To my understanding, this is a cgi script problem, and that I must create a web server in order to test this script.
And heres were I’m stuck. I know little to nothing about web servers and how to set them up. On top of that I’ve heard that GCI scripting is a thing of the past, and requires major overhead in order to run properly.
This leads to my questions. How do I go about completing my app and testing my cgi script? Do I install apache and mess around with it or should I be looking into something like google app engine? Are there other ways to complete this task without cgi scripts? Where do frameworks like Django fit into this?

Django, while being nice, all-encompassing and well-supported, is sometimes too much for a small web application. Django wants you to play by its rules from the beginning, you'll have to avoid things like the database and admin panels if you don't need them. It's also easier, with Django, to follow its project layout, even when it's too complex for a simple app.
The so-called micro frameworks might suit you better for your small app. They are built upon the opposite principle: use the bare minimum of features now, add more as you need them.
Flask is based on Werkzeug WSGI library and Jinja2 templating (the latter is switchable), is extensively documented (with notes concerning virtualenv and stuff) and well-suited for small and larger apps alike. It comes bundled with an auto-reloading dev server (no need for Apache on your dev machine) and Werkzeug-powered interactive debugger. There are extensions for things like HTML forms and database ORM.
Bottle is as small as a microframework can get, consisting of 1 (one) file, dev server included. Drop it into your project folder and start hacking. The built-in SimpleTemplate templating engine is switchable, but the dev server is flakier in comparison to Flask's. The documentation is less complete, and, in my opinion, the whole thing is less polished and convenient as Flask.
In both cases, you use dev server locally, and then deploy using WSGI, the server interface for Python web apps which both frameworks support. There are many ways to deploy a WSGI app, Apache mod_wsgi being one of the popular ones.
I'd totally go with Flask unless one dependency (Bottle) is better than three (Flask, Jinja2 and Werkzeug).
(There are many other frameworks as well, so wait for their users to come and tell about them. I'd suggest to avoid web.py: it works, but is full of magic, and is inelegant compared to Flask or Bottle.)

One way of getting to working webapp quickly is by first understanding, and then modifying, something like the App Engine "guestbook" example. This has the benefit that much of the otherwise necessary tedium of running a web server and setting up a database server (assuming you need persistence) is done for you. App Engine also provides a fairly flexible development environment. It's certainly not the only way to go, and I'll admit to bias in recommending it, but it's fairly low friction.
GCI scripting is hardly a thing of the past, though it's not what the cool kids are doing. CGI has the benefit, and the curse, of exposing more of the raw plumbing. It forces you to understand a lot about primitive (in the low-level sense) web architecture, but it's also a bit of a large bite to chew on if you have an immediate problem to solve that can solved by simpler means.

It appears most python web development seems to be done by frameworks these days. There are a couple reasons for this:
a plethora of mature tools. Django has built in user auth, built in database management, built in sessions, built in just about everything ORM which lets you seamlessly supports a couple databases.
Built in webservers. The larger python frameworks like django and pylons have built in webservers. Django has a very simple webserver python manage.py startserver (that simple) That makes it extremely easy to create and debug applications. It is single threaded so dropping a debugger into it is painless
Huge communities. If you have a django question it will be answered very quickly the so community is huge.
The django tutorial will introduce you to all the major aspects of development. It is only 4 pages and you will be able to get your app going a lot simpler than having to read, learn and fiddle with an apache setup.
https://docs.djangoproject.com/en/dev/intro/tutorial01/
Although django for right now might be overkill if your app is just going to be 1 form and a script to process it. Because of its seamless testing framework it is quite easy to grow any project. I have never used flask or bottle or the other microframeworks, but I would keep in mind where your project will be in the future.
As for where django fits into this, it is a full stack framework encompassing presentation (templates), data management (server orm), authentication, middleware, forms ... everything necessary to create a completely inclusive web application. Django and almost all other python frameworks implement the wsgi standard. It is an interface that allows for interoperation between webservers. http://en.wikipedia.org/wiki/Web_Server_Gateway_Interface it is pretty dry and you will never have to interface it directly. That is what these frameworks do under the hood.

Why setup and maintain your own webserver if you can use app engine. It has an excellent SDK for testing your code. Here is an example https://developers.google.com/appengine/docs/python/gettingstarted/handlingforms
And Django you will find here : https://developers.google.com/appengine/docs/python/gettingstarted/templates
I prefer to use Jinja for templating.

Django comes with its own server, but in your case i would recommend apache and mod_python since it seems to be a rather simple site you're building.
Setting up Apache is a breeze and a simple search on the web should give you all you need.
You can find more information on mod_python here read up a little bit on it and then google after a tutorial that fits your needs.

Suggest a standalone python web framework?

I have a python program that I would like to present as a simple web application. The program currently uses sqlite for storage. I also need to distribute the whole thing to colleagues so having something standalone and easy to start would be ideal ( no install if possible). This web app is meant to be used locally , not by multiple users over a network.
Is there a suitable python framework that might fit my needs? I looked at Django so far but it seems a bit heavy handed for what I need.
Thanks for any suggestions.

I have never tried it myself, but you could try Bottle:
Bottle is a fast, simple and lightweight WSGI micro web-framework for
Python. It is distributed as a single file module and has no
dependencies other than the Python Standard Library.

try http://docs.python.org/library/simplehttpserver.html

As web frameworks are not part of the standard lib, you will have to install something in every case. I would propse to look at http://flask.pocoo.org/. It has a build in WSGI server.

Lots of choices for Python web frameworks! Another is web2py which is designed to work out of the box and allows, but doesn't require, through-the-web development. It is mature and has a strong community and is well-documented.

Tornado as a framework may be a lot more than what you're looking for. However it will meet the requirement of being a completely python based web server. http://tornadoweb.org
I generally just download the source, drop it in /tornado/ of my project and do includes there from the app.

I don't think that any web framework is specifically oriented for the use case you're talking about; They all assume they are running on a server and there's a browser on a remote machine that is accessing them.
A better approach is to think about the HTTP server you'll be using. It's probably preferable to use a server that's as easy to pack and ship as the rest of the python code you'll be using. Now most frameworks provide a 'development' server that's easy to invoke from the command line, but most of them are intended to be "easy for the developer" which often means they are restricted to a single thread. This is bad for deployment because single threaded servers will always feel a bit sluggish.
CherryPy stands out in contrast, by providing a full featured, embedded server that's easy to configure for many use cases, and is available by default with the rest of the framework. There are probably others, but I haven't used 'em.

How do you deploy your WSGI application? (and why it is the best way)

I am deploying a WSGI application. There are many ways to skin this cat. I am currently using apache2 with mod-wsgi, but I can see some potential problems with this.
So how can it be done?
Apache Mod-wsgi (the other mod-wsgi's seem to not be worth it)
Pure Python web server eg paste, cherrypy, Spawning, Twisted.web
as 2 but with reverse proxy from nginx, apache2 etc, with good static file handling
Conversion to other protocol such as FCGI with a bridge (eg Flup) and running in a conventional web server.
More?
I want to know how you do it, and why it is the best way to do it. I would absolutely love you to bore me with details about the whats and the whys, application specific stuff, etc.

As always: It depends ;-)
When I don't need any apache features I am going with a pure python webserver like paste etc. Which one exactly depends on your application I guess and can be decided by doing some benchmarks. I always wanted to do some but never came to it. I guess Spawning might have some advantages in using non blocking IO out of the box but I had sometimes problems with it because of the patching it's doing.
You are always free to put a varnish in front as well of course.
If an Apache is required I am usually going with solution 3 so that I can keep processes separate. You can also more easily move processes to other servers etc. I simply like to keep things separate.
For static files I am using right now a separate server for a project which just serves static images/css/js. I am using lighttpd as webserver which has great performance (in this case I don't have a varnish in front anymore).
Another useful tool is supervisord for controlling and monitoring these services.
I am additionally using buildout for managing my deployments and development sandboxes (together with virtualenv).

I would absolutely love you to bore me with details about the whats and the whys, application specific stuff, etc
Ho. Well you asked for it!
Like Daniel I personally use Apache with mod_wsgi. It is still new enough that deploying it in some environments can be a struggle, but if you're compiling everything yourself anyway it's pretty easy. I've found it very reliable, even the early versions. Props to Graham Dumpleton for keeping control of it pretty much by himself.
However for me it's essential that WSGI applications work across all possible servers. There is a bit of a hole at the moment in this area: you have the WSGI standard telling you what a WSGI callable (application) does, but there's no standardisation of deployment; no single way to tell the web server where to find the application. There's also no standardised way to make the server reload the application when you've updated it.
The approach I've adopted is to put:
all application logic in modules/packages, preferably in classes
all website-specific customisations to be done by subclassing the main Application and overriding members
all server-specific deployment settings (eg. database connection factory, mail relay settings) as class __init__() parameters
one top-level ‘application.py’ script that initialises the Application class with the correct deployment settings for the current server, then runs the application in such a way that it can work deployed as a CGI script, a mod_wsgi WSGIScriptAlias (or Passenger, which apparently works the same way), or can be interacted with from the command line
a helper module that takes care of above deployment issues and allows the application to be reloaded when the modules the application is relying on change
So what the application.py looks like in the end is something like:
#!/usr/bin/env python
import os.path
basedir= os.path.dirname(__file__)
import MySQLdb
def dbfactory():
return MySQLdb.connect(db= 'myappdb', unix_socket= '/var/mysql/socket', user= 'u', passwd= 'p')
def appfactory():
import myapplication
return myapplication.Application(basedir, dbfactory, debug= False)
import wsgiwrap
ismain= __name__=='__main__'
libdir= os.path.join(basedir, 'system', 'lib')
application= wsgiwrap.Wrapper(appfactory, libdir, 10, ismain)
The wsgiwrap.Wrapper checks every 10 seconds to see if any of the application modules in libdir have been updated, and if so does some nasty sys.modules magic to unload them all reliably. Then appfactory() will be called again to get a new instance of the updated application.
(You can also use command line tools such as
./application.py setup
./application.py daemon
to run any setup and background-tasks hooks provided by the application callable — a bit like how distutils works. It also responds to start/stop/restart like an init script.)
Another trick I use is to put the deployment settings for multiple servers (development/testing/production) in the same application.py script, and sniff ‘socket.gethostname()’ to decide which server-specific bunch of settings to use.
At some point I might package wsgiwrap up and release it properly (possibly under a different name). In the meantime if you're interested, you can see a dogfood-development version at http://www.doxdesk.com/file/software/py/v/wsgiwrap-0.5.py.

The absolute easiest thing to deploy is CherryPy. Your web application can also become a standalone webserver. CherryPy is also a fairly fast server considering that it's written in pure Python. With that said, it's not Apache. Thus, I find that CherryPy is a good choice for lower volume webapps.
Other than that, I don't think there's any right or wrong answer to this question. Lots of high-volume websites have been built on the technologies you talk about, and I don't think you can go too wrong any of those ways (although I will say that I agree with mod-wsgi not being up to snuff on every non-apache server).
Also, I've been using isapi_wsgi to deploy python apps under IIS. It's a less than ideal setup, but it works and you don't always get to choose otherwise when you live in a windows-centric world.

Nginx reverse proxy and static file sharing + XSendfile + uploadprogress_module. Nothing beats it for the purpose.
On the WSGI side either Apache + mod_wsgi or cherrypy server. I like to use cherrypy wsgi server for applications on servers with less memory and less requests.
Reasoning:
I've done benchmarks with different tools for different popular solutions.
I have more experience with lower level TCP/IP than web development, especially http implementations. I'm more confident that I can recognize a good http server than I can recognize a good web framework.
I know Twisted much more than Django or Pylons. The http stack in Twisted is still not up to this but it will be there.

I'm using Google App Engine for an application I'm developing. It runs WSGI applications.
Here's a couple bits of info on it.
This is the first web-app I've ever really worked on, so I don't have a basis for comparison, but if you're a Google fan, you might want to look into it. I've had a lot of fun using it as my framework for learning.

TurboGears (2.0)
TurboGears 2.0 is leaving Beta within the next month (has been in it for plenty of time). 2.0 improves upon 1.0 series and attempts to give you best-of-breed WSGI stack, so it makes some default choices for you, if you want the least fuss.
it has the tg* tools for testing and deployment in 1.x series, but now transformed to paster equivalents in 2.0 series, which shoud seem familiar if you've expermiented with pylons.
tg-admin quickstart —> paster quickstart
tg-admin info —> paster tginfo
tg-admin toolbox –> paster toolbox
tg-admin shell –> paster shell
tg-admin sql create –> paster setup-app development.ini
Pylons
It you'd like to be more flexible in your WSGI stack (choice of ORM, choice of templater, choice of form-ing), Pylons is becoming the consolidated choice. This would be my recommended choice, since it offers excellent documentation and allows you to experiment with different components.
It is a pleasure to work with as a result, and works on under Apache (production deployment) or stand-alone (helpful for testing and experimenting stage).
so it follows, you can do both with Pylons:
2 option for testing stage (python standalone)
4 for scalable production purposes (FastCGI, assuming the database you choose can keep up)
The Pylons admin interface is very similar to TurboGears. Here's a toy standalone example:
$ paster create -t pylons helloworld
$ cd helloworld
$ paster serve --reload development.ini
for production-class deployment, you could refer to the setup guide of Apache + FastCGI + mod_rewrite is available here. this would scale up to most needs.

Apache httpd + mod_fcgid using web.py (which is a wsgi application).
Works like a charm.

We are using pure Paste for some of our web services. It is easy to deploy (with our internal deployment mechanism; we're not using Paste Deploy or anything like that) and it is nice to minimize the difference between production systems and what's running on developers' workstations. Caveat: we don't expect low latency out of Paste itself because of the heavyweight nature of our requests. In some crude benchmarking we did we weren't getting fantastic results; it just ended up being moot due to the expense of our typical request handler. So far it has worked fine.
Static data has been handled by completely separate (and somewhat "organically" grown) stacks, including the use of S3, Akamai, Apache and IIS, in various ways.

Apache+mod_wsgi,
Simple, clean. (only four lines of webserver config), easy for other sysadimns to get their head around.

Python web programming

Good morning.
As the title indicates, I've got some questions about using python for web development.
What is the best setup for a development environment, more specifically, what webserver to use, how to bind python with it. Preferably, I'd like it to be implementable in both, *nix and win environment.
My major concern when I last tried apache + mod_python + CherryPy was having to reload webserver to see the changes. Is it considered normal? For some reason cherrypy's autoreload didn't work at all.
What is the best setup to deploy a working Python app to production and why? I'm now using lighttpd for my PHP web apps, but how would it do for python compared to nginx for example?
Is it worth diving straight with a framework or to roll something simple of my own? I see that Django has got quite a lot of fans, but I'm thinking it would be overkill for my needs, so I've started looking into CherryPy.
How exactly are Python apps served if I have to reload httpd to see the changes? Something like a permanent process spawning child processes, with all the major file includes happening on server start and then just lazy loading needed resources?
Python supports multithreading, do I need to look into using that for a benefit when developing web apps? What would be that benefit and in what situations?
Big thanks!

What is the best setup for a development environment?
Doesn't much matter. We use Django, which runs in Windows and Unix nicely. For production, we use Apache in Red Hat.
Is having to reload webserver to see the changes considered normal?
Yes. Not clear why you'd want anything different. Web application software shouldn't be dynamic. Content yes. Software no.
In Django, we develop without using a web server of any kind on our desktop. The Django "runserver" command reloads the application under most circumstances. For development, this works great. The times when it won't reload are when we've damaged things so badly that the app doesn't properly.
What is the best setup to deploy a working Python app to production and why?
"Best" is undefined in this context. Therefore, please provide some qualification for "nest" (e.g., "fastest", "cheapest", "bluest")
Is it worth diving straight with a framework or to roll something simple of my own?
Don't waste time rolling your own. We use Django because of the built-in admin page that we don't have to write or maintain. Saves mountains of work.
How exactly are Python apps served if I have to reload httpd to see the changes?
Two methods:
Daemon - mod_wsgi or mod_fastcgi have a Python daemon process to which they connect. Change your software. Restart the daemon.
Embedded - mod_wsgi or mod_python have an embedded mode in which the Python interpreter is inside the mod, inside Apache. You have to restart httpd to restart that embedded interpreter.
Do I need to look into using multi-threaded?
Yes and no. Yes you do need to be aware of this. No, you don't need to do very much. Apache and mod_wsgi and Django should handle this for you.

So here are my thoughts about it:
I am using Python Paste for developing my app and eventually also running it (or any other python web server). I am usually not using mod_python or mod_wsgi as it makes development setup more complex.
I am using zc.buildout for managing my development environment and all dependencies together with virtualenv. This gives me an isolated sandbox which does not interfere with any Python modules installed system wide.
For deployment I am also using buildout/virtualenv, eventually with a different buildout.cfg. I am also using Paste Deploy and it's configuration mechanism where I have different config files for development and deployment.
As I am usually running paste/cherrypy etc. standalone I am using Apache, NGINX or maybe just a Varnish alone in front of it. It depends on what configuration options you need. E.g. if no virtual hosting, rewrite rules etc. are needed, then I don't need a full featured web server in front. When using a web server I usually use ProxyPass or some more complex rewriting using mod_rewrite.
The Python web framework I use at the moment is repoze.bfg right now btw.
As for your questions about reloading I know about these problems when running it with e.g. mod_python but when using a standalone "paster serve ... -reload" etc. it so far works really well. repoze.bfg additionally has some setting for automatically reloading templates when they change. If the framework you use has that should be documented.
As for multithreading that's usually used then inside the python web server. As CherryPy supports this I guess you don't have to worry about that, it should be used automatically. You should just eventually make some benchmarks to find out under what number of threads your application performs the best.
Hope that helps.

+1 to MrTopf's answer, but I'll add some additional opinions.
Webserver
Apache is the webserver that will give you the most configurability. Avoid mod_python because it is basically unsupported. On the other hand, mod_wsgi is very well supported and gives you better stability (in other words, easier to configure for cpu/memory usage to be stable as opposed to spikey and unpredictable).
Another huge benefit, you can configure mod_wsgi to reload your application if the wsgi application script is touched, no need to restart Apache. For development/testing servers you can even configure mod_wsgi to reload when any file in your application is changed. This is so helpful I even run Apache+mod_wsgi on my laptop during development.
Nginx and lighttpd are commonly used for webservers, either by serving Python apps directly through a fastCGI interface (don't bother with any WSGI interfaces on these servers yet) or by using them as a front end in front of Apache. Calls into the app get passed through (by proxy) to Apache+mod_wsgi and then nginx/lighttpd serve the static content directly.
Nginx has the added advantage of being able to serve content directly from memcached if you want to get that sophisticated. I've heard disparaging comments about lighttpd and it does seem to have some development problems, but there are certainly some big companies using it successfully.
Python stack
At the lowest level you can program to WSGI directly for the best performance. There are lots of helpful WSGI modules out there to help you in areas you don't want to develop yourself. At this level you'll probably want to pick third-party WSGI components to do things like URL resolving and HTTP request/response handling. A great request/response component is WebOb.
If you look at Pylons you can see their idea of "best-of-breed" WSGI components and a framework that makes it easier than Django to choose your own components like templating engine.
Django might be overkill but I don't think that's a really good argument against. Django makes the easy stuff easier. When you start to get into very complicated applications is where you really need to look at moving to lower level frameworks.

Look at Google App Engine. From their website:
Google App Engine lets you run your
web applications on Google's
infrastructure. App Engine
applications are easy to build, easy
to maintain, and easy to scale as your
traffic and data storage needs grow.
With App Engine, there are no servers
to maintain: You just upload your
application, and it's ready to serve
your users.
You can serve your app using a free
domain name on the appspot.com domain,
or use Google Apps to serve it from
your own domain. You can share your
application with the world, or limit
access to members of your
organization.
App Engine costs nothing to get
started. Sign up for a free account,
and you can develop and publish your
application for the world to see, at
no charge and with no obligation. A
free account can use up to 500MB of
persistent storage and enough CPU and
bandwidth for about 5 million page
views a month.
Best part of all: It includes Python support, including Django. Go to http://code.google.com/appengine/docs/whatisgoogleappengine.html

When you use mod_python on a threaded Apache server (the default on Windows), CherryPy runs in the same process as Apache. In that case, you almost certainly don't want CP to restart the process.
Solution: use mod_rewrite or mod_proxy so that CherryPy runs in its own process. Then you can autoreload to your heart's content. :)

Can I write Python web application for Windows and Linux platforms at the same time?

Can I write web application that I can host on Windows(IIS web server) and Linux (Apache or lighttpd) without any changes?
CGI? Maybe something new? WSGI | FastCGI ?

Yes you can. But you can also use apache on windows. If you go the IIS way there's only CGI and it's pretty hard to set up. You can also use python based server like CherryPy which is pretty good and will work on all platforms with python.
Some frameworks like django support both CGI and WSGI, so you don't have to worry about the details of WSGI or CGI much.
If you ask me, WSGI is the future for python web apps.

web.py includes a server... It will do the trick for small jobs.
By the way, Apache works on windows.

Yes, if you use CGI, FastCGI or depending on your framework, even a self-contained web server (so IIS and Apache would be a reverse-proxy) then that would all work.
The difference will be the configuration of the OS-specific servers, and also your Python environment on each OS. So you may find yourself doing a small bit of work at the beginning to make sure your paths are right, etc.

A rather big Python based web framework is ZOPE.
Zope is an open source application server for building content management systems, intranets, portals, and custom applications. The Zope community consists of hundreds of companies and thousands of developers all over the world, working on building the platform and Zope applications. Zope is written in Python, a highly-productive, object-oriented scripting language
ZOPE is available on Linux and Windows, and you can use Python to write your Zope Web Apps (it includes a simpler templating system, too).

consider also the possibility of using web2Py, or XML-RPC implementation, or Twisted...

Writing python web apps is a topic on itself, but I would say that by default, it will be portable on multiple servers / platforms.
When developping python web applications, you will often use frameworks that provide their own web server. For performance reasons, you might want to place it behind apache, but it is not even necessary, however, you might get a performance boost by placing it behind an apache server.
Some of the most popular frameworks for web python are : Plone, Zope, CherryPy and TurboGears, only to name a few.
Under apache, you could also use python server pages through mod_python, and since apache runs on windows too, this would aslo be portable.