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 -- http://mail.python.org/mailman/listinfo/python-list
