On Sat, 2007-03-10 at 20:53 -0600, James Bennett wrote: > While working on a small personal project I've run into a bit of a > wall because I'd like to use a third-party module which looks for > information about HTTP requests. It doesn't know (and shouldn't need > to know) about Django's HttpRequest object, and simply looks for the > things it wants in os.environ, because Python CGI will usually put > information about the request in there.
[Insert standard rant about components intended to be reusable that do not provide an alternative way to specify the environment. Makes testing kind if hard. Their developers are probably cruel to small animals as well.] > Since there seems to be a fair amount of Python software out there > which uses this convention, how would folks feel about having > HttpRequest.__init__ populate os.environ with the standard keys for > CGI data? As far as I can tell it's a fairly simple enhancement, and > it'd make a lot of existing tools easier to use inside Django. Seems reasonable. One tricky aspect of this that I've come across in the past is if you try to make it multi-threaded safe: if the web server sends a custom variable across in the "environment" (e.g. Apache's ability to send any var you like), you need to ensure it is blanked out (unset, if possible, otherwise set to something empty) again at the end of the request. If you don't do this, you get cross-request pollution and it's sort of the opposite of fun to debug. Other than that, I can't think of any real downside. Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
