2008/11/18 Nimrod A. Abing <[EMAIL PROTECTED]>: > > On Mon, Nov 17, 2008 at 10:42 PM, Clodoaldo Pinto Neto > <[EMAIL PROTECTED]> wrote: >> >> 2008/11/17 Graham Dumpleton <[EMAIL PROTECTED]>: >>> >>> Hmmmm, someone else who thinks they can do better than what is out >>> there for Python support in conjunction within Apache. >>> >>> http://blog.code-head.com/lets-make-python-web-friendly >> >> There is nothing there other than vapor, if that much. One thing he >> has already demonstrated: he has no clue about CGI and mod_python. > > While I agree with you on the cluelessness of that post, I do agree > with some of the points there. > > If I understand his post correctly, he is setting out to bring > complete and total simplicity to the deployment of Python-based web > apps. That is, write a Python app. Upload it to server and it runs. No > frills, no conventions to follow, no standards to adhere to. No > fiddling around with Apache configuration files. No need for root > access to the server. > > This is why PHP is so popular especially for noobs. The idea that you > can write a dynamic web-based application without caring about things > like the CGI standard. There is no need to import any special module > (import cgi). There is no need to adhere to conventions (def > application()) to get things to work properly. No need to fiddle > around with Apache configuration files to get URL-to-app mappings > (WSGIScriptAlias).
You still need to configure Apache to have it handle .php files. The only difference is that hosting providers have done it for you already and so mere mortals don't have to. The amount of configuration needed to get mod_wsgi to handle arbitrary .wsgi files as applications isn't much different. For example, for PHP you need at least something like: AddType application/x-httpd-php .php For mod_wsgi you need: AddHandler wsgi-script .wsgi Options ExecCGI That is, you don't need to use WSGIScriptAlias, you can just use AddHandler applied to a directory just like PHP does. Doing this though will result in extension appearing in URL just like in PHP. This can be eliminated in the case of both PHP and mod_wsgi using: Options MultiViews MultiviewsMatch Handlers An administrator could just as easily set this up before hand for users for mod_wsgi as they could for PHP, such that there is no need for a user to have root access to be able to add a WSGIScriptAlias directive. So, at that level of configuration there isn't really much difference. This isn't the real problem though, the bigger issue is the persistence of Python web applications. How this contrasts to PHP is quite well described by Ian Bicking in: http://blog.ianbicking.org/2008/01/12/what-php-deployment-gets-right/ Although the above configuration is simple and could be set up before hand, as is things would run in main Apache worker processes and because Python code persists and isn't stripped down after requests, you need to restart Apache after code changes are made. The daemon mode in mod_wsgi is a part solution to this, but as it is now, it requires WSGIDaemonProcess/WSGIProcessGroup for each user to be set up and configured. Although this may not be a big problem if administrator has to create a VirtualHost container for user anyway, it isn't if they use database driven virtual hosting. To cope with this, have already described idea for transient daemon process and wild carding configuration so can be driven from database. This is described in: http://code.google.com/p/modwsgi/issues/detail?id=22 > He just wants to upload a Python program and go. He wants to be able > to say print "Hello World" without having something on the server say, > "No I can't let you do that, Dave.". In mod_wsgi, if you wanted to do > that you need to set WSGIRestrictStdin off, something you cannot do if > you don't have root access to the server. Setting WSGIRestrictStdin to Off isn't going to help here as that will just mean output of 'print' goes to Apache error log file. They want output of 'print' to end up in response. The web.py folks tried this as have Karrigell people. What they do is simply reassign sys.stdout to make it go somewhere else. In Karrigell though they do it in a simplistic way at start of each request. Result of that is that it can't run in multithreaded server. In web.py they try to use a thread aware replacement for sys.stdout, possibly relying on threading.local internally to track which response to send back to. In both cases though it can screw up because of the third party Python modules whole like to also use 'print' for outputting debug, which rather than end up in log, ends up in your response by accident. Thus, 'print' is not necessarily a good solution. Even if you did byte code manipulation to change where 'print' goes by default, such as done in Werkzeug or Jinja (can't remember which), that only extends to the top level template file and not to Python modules they may call which would be unexpected if they always expect 'print' to go to response. BTW, as documented, instead of WSGIRestrictStdin you can just say: sys.stdout = sys.stderr > Horror of horrors, maybe he wants to be able to have <?py print "Hello > World" ?>. As far as I know there is nothing out there that lets you > do it that simple. In mod_python you still need to write a handler and > pass content to the psp module. In mod_python using SSI you can write: <!--#python exec=" print >> filter, "Hello World" " --> > In other words, he wants to turn Python into a preprocessing language > in the same vein as PHP. If he pulls it off, then good for him. Personally I believe a very simple means of embedding Python code in pages would be useful as well and Python support in SSI part satisfies that. As you see above though, you still have to redirect to the 'filter' object. What I wanted to do was do the byte code manipulation I spoke of so that one could instead just write: <!--#python exec=" print "Hello World" " --> I could see being able to do all sorts of optimisations over how it works now. For example, it compiles the Python code on each request whereas it could cache the byte code from request to request and purge code from pages not accessed in a while. Anyway, part of the reason why I challenge people when I see such posts is to really find out how much they know about what else exists out there. I suspect not many would realise that mod_python has support for Python code using SSI nor prior efforts to overload 'print' for collecting response content. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
