Trying to understand Python web-development

[Bruno Desthuilliers]

walterbyrd a écrit :
> I don't know much php either, but running a php app seems straight
> forward enough.

Mmm... As long as the whole system is already installed and connfigured, 
*and* matches your app's expectations, kind of, yes.

> Python seems to always use some sort of development environment vs
> production environment scheme.

s/Python/some frameworks/

> For development, you are supposed to
> run a local browser and load 127.0.0.1:5000 - or something like that.
> Then to run the same thing in a development environment,

I suppose you meant "in a production environment" ?

> I have to
> configure some files, or touch all the files, restart the web-server,
> or something. Why is that?

Developping directly on a production server is defiinitively a no-no, 
whatever the language. So you *always* develop un a development 
environment. In PHP, this imply having a running HTTP server - usually 
Apache - correctly configured. Some Python frameworks, OTHO, ship with 
their own lightweight Python-based http server, which usually makes 
things far easier. Since quite a lot of web programmers already have 
Apache running on port 80, the framework's own server usually runs (by 
default) on another port. Also, most of the time, on the production 
server, you choose some other more appropriate deployement solution - 
which may or not include Apache - depending on the context. So the nice 
point here is that:
1/ you have way more freedom wrt/ possible deployment solutions
2/ you don't have to replicate the whole damn thing (if ever possible) 
on your local machine to develop the app.

Of course, the actions to be taken when updating your app on the 
production server greatly depends on the deployment solution.

> Python also seems to require some sort of "long running processes" I
> guess that the python interpretor has to running all of time.

s/Python/some frameworks/

You can write web apps in Python using plain cgi, you know. It's just 
very inefficient due to how cgi works - to make a long story short: the 
system has to launch a new process for each request calling your script, 
and you have to rebuild the whole damn world each time your script is 
called. Note that PHP suffers at least from the second problem, which 
can make it somewhat inefficient for some kind of applications.

The point of long running processes is that most of the world is only 
built at startup and stays here between requests.

> I am not really sure about what wsgi is supposed to accomplish.

First and mainly, allow Python-based web apps to be independant from the 
deployment solution, by adding an indirection level. Instead of having

[yourapp]<-->[http_server]

which only work for the http server you targeted, you have

[yourapp]<-->[wsgi]<-->[http_server.wsgi_adapter]<-->[http_server]

which works for any http server for which a specific wsg adapter exists.

There are also some other benefits since, the way wsgi works, the [wsgi] 
part of the above schema can include quite a lot of other things, 
sometimes without your application being aware of it (you may want to 
look for 'wsgi middleware' for more on this).


HTH