Hi, I've been looking at ways to add more dynamic logging to my applications and naturally looked to the django signals as a way to do it.
I'm unsure of the logic behind the request handler class being returned in the request_finished and request_started signals, rather than the actual instance. I was wondering if some more enlightened developer could explain the logic behind such a decision - one of the lines of code in question is in core.handlers.wsgi line 246: signals.request_finished.send(sender=self.__class__) I'm pondering why the instance itself is not sent, as this would contain lots of pertinent information. I'm speculating it could be for a few reasons - to ensure that the handler is garbage collected after each request - if loads of pointers are floating about, then a badly written signal handler could cause some sort of memory leak? Or perhaps to avoid a signal handler mutating the request handler? Either way - it'd be useful to actually have the instance available - I'm interested to whether I guessed the reasons right? Thanks, Peter (I deliberated whether this was a django-users question, but as I'm more interested in the motivation of the decision rather than a fix, I figured this was the right place) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" 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/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
