On Sun, Jan 25, 2009 at 10:45 PM, Almad <b...@almad.net> wrote: > > For those interested, patch from #3357 works nicely and can be started > from within: > http://devel.almad.net/trac/django-sane-testing/changeset/d2c24247d7e4 > > However, it's still buggy for my case. If You want it too, You can use > CP WSGI as suggested by mikeal some time ago, I'm now using it too: > http://devel.almad.net/trac/django-sane-testing/changeset/00d317877c55 > > I still feel kinda weird that I must hack around Django so much to > make basic testing things working :-]]]
Let's be clear here - the "basic testing" thing that is failing here is a very specific, and somewhat esoteric edge case - the case of a view that invokes, via HTTP, another view on the same server. Client side AJAX self-calls and using urllib to call a URL on another server won't lock up the Django development server. The Django core team has (repeatedly) made a very deliberate decision to keep the development server single threaded. There are many very good web servers out there - Django isn't trying to get into the game of competing with any of them. We view Django's job as providing a good web stack for a real web server to use; the development server is provided as a convenience, nothing more. Having a singlethreaded server makes the implementation much simpler, so we can concentrate our efforts on making a great web stack, rather than wasting effort on writing, debugging, and maintaining a web server that we don't really want people to use for serious work. A multithreaded server would also act as a tacit encouragement to use Django's development server for real deployments, which we _really_ don't want to encourage. If people start using Django's development server in production, we would have to start treating it as a production-ready server - doing security and performance audits and the like - and again, this distracts us from what we consider to be the "main game". The _only_ type of view that is affected by this decision is the view that uses urllib (or equivalent) to invoke another view on the same server. We (the Django core team) have decided that this is a compromise we can live with. The set of cases where this behavior is required is very small, doesn't form a part of the requirements for most (almost all) web development projects. For that small subset of users that _do_ have a legitimate use for this, there are some lightweight multithreaded options (like CherryPy) out there, and to the best of my knowledge, none of these options _require_ the patching of core in order to use them. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
