|
Graham Dumpleton
graham.dumpleton at gmail.com
Mon Jun 23 05:16:29 EDT 2008
Please keep replies on list. 2008/6/23 Massimo Di Pierro <MDiPierro at cs.depaul.edu>: > I agree it makes perfect sense within mod_python. But how Django must write > in os.environ in order to use it on top of mod_wsgi. Am I wrong? I meant to say 'It is okay read only, which is how Django uses it'. If you think it makes perfect sense in mod_python, then I am not sure how as that isn't what I meant to say. :-) Django itself doesn't write to os.environ. As a hack they allow mod_python adapter for Django to write into it, but that is outside of Django proper. Rather poorly, they do it on every request. Technically this would be bad if the value changes on every request, but in general it wouldn't change, so just redundant. In mod_wsgi it is the WSGI script which sets up the Django instance that needs to write to os.environ before importing Django. This is only done when the script is first loaded however and not on every request. Either way, a WSGI friendly application would have a configuration parameter passed through the WSGI environment dictionary and as such be able to be changed on every request if need be. Trac for example does this, and because they properly isolate project areas, can thus host multiple project areas in one interpreter instance. Graham > > Massimo > > On Jun 22, 2008, at 9:32 PM, Graham Dumpleton wrote: > >> It is okay read only, which is how mod_python uses it. >> >> 2008/6/23 Massimo Di Pierro <MDiPierro at cs.depaul.edu>: >>> >>> Am I wrong or using os.environ is not even thread safe? >>> Are you also saying that Django 1.0 will continue to use os.environ? >>> >>> Massimo >>> >>> On Jun 22, 2008, at 9:10 PM, Graham Dumpleton wrote: >>> >>>> It wasn't listed because I believe it was already stated by OP that it >>>> worked with WSGI and thus they knew that already. I therefore didn't >>>> need to tell him. >>>> >>>> As much as many frameworks can run on WSGI and may even state or aim >>>> to be 100% WSGI compliant, that doesn't mean they fit with some of the >>>> greater ideals of WSGI that some would like to see. The thing which >>>> Django folks will not be addressing is their reliance on os.environ to >>>> define location of configuration information. WSGI doesn't say they >>>> can't do this, but relying on global data like that in any WSGI >>>> compliant framework limits one to having one instance of that >>>> framework within a Python interpreter instance. This makes it >>>> impossible with one Python interpreter instance to mount more than one >>>> application reliant on that framework. Thus one is forced to use >>>> multiple processes and/or interpreters instead. >>>> >>>> Graham >>>> >>>> 2008/6/22 Massimo Di Pierro <mdipierro at cs.depaul.edu>: >>>>> >>>>> I read the post again and I noticed you omitted web2py from the list of >>>>> "major frameworks" that support wsgi. I would like to add that web2py >>>>> uses >>>>> the cherrypy 3.0 wsgiserver (unmodified) so it is as wsgi compliant as >>>>> cherrypy is. Django instead, for example, lists "Making Django 100% >>>>> WSGI >>>>> compliant." as one of the roadmark targets for version 1.0. >>>>> Massimo >>>>> On Jun 21, 2008, at 9:44 AM, Massimo Di Pierro wrote: >>>>> >>>>> Dear Graham, >>>>> a couple of months ago you send me some very constructive comments >>>>> about >>>>> web2py. In particular you suggested that we replaced all relative paths >>>>> with >>>>> absolutes paths. I really appreciate your advice and this issue was >>>>> addressed within one week of your email. If there is any other issue >>>>> that >>>>> you find with the web2py source code, please let us know and it will be >>>>> addresses. At this point we are not aware of any open issue. >>>>> You also refer to "heard various critiques by others about it". Could >>>>> you >>>>> be >>>>> more explicit? Unfortunately there are many incorrect posts online >>>>> about >>>>> web2py written by people who have not tried it or read the specs. >>>>> Massimo >>>>> >>>>> Graham Dumpleton graham.dumpleton at gmail.com write: >>>>>> >>>>>> All the major frameworks support WSGI, Django, TurboGears, Pylons, >>>>>> CherryPy, web.py and up and comers such as Werkzeug. >>>>>> Although Django may say use mod_python, general consensus is rapidly >>>>>> moving to use of mod_wsgi, it is just that developers who maintain web >>>>>> site haven't decided yet to make a statement that mod_wsgi is equally >>>>>> as capable as mod_python. >>>>>> As to web2py, it would not be one of my first choices. It may be more >>>>>> glitzy and have better marketing speak around it, but having seen some >>>>>> of the code in it and heard various critiques by others about it, I'd >>>>>> be looking elsewhere. I'd probably suggest Django for high level >>>>>> framework and Werkzeug if you want a more low level nuts and bolts >>>>>> approach. >>>>>> >>>>>> Graham<ATT00001.txt> >>>>> >>>>> _______________________________________________ >>>>> Mod_python mailing list >>>>> Mod_python at modpython.org >>>>> http://mailman.modpython.org/mailman/listinfo/mod_python >>>>> >>>>> >>> >>> > >
|