On Wed, Oct 1, 2008 at 4:04 PM, Marc Fargas <[EMAIL PROTECTED]> wrote: > The thing is, it's a really nice place to emit a signal if you want to > do things "just after things are ready", but there's no signal for it.
Just after *what* is ready, precisely? After "import django" has succeeded? After settings have been imported? After model caches have been initialized? After a request handler has been instantiated (which we already sort of have a signal for)? This is one of many problems with a "Django is ready" signal -- everybody's going to have a use case which demands a different definition of what "ready" means. As it is, you have a signal which fires when we start processing an HTTP request, and that's what most people should look to since Django is, fundamentally, about cycles of HTTP request/HTTP response and so that's the most useful mindset to have. Failing that, there are plenty of well-established Python idioms for "run this code once and only once the first time I'm imported", which covers the remainder of the use cases (or really stubborn people who want to act like Django is a desktop application instead of a web framework). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
