On Tue, 2009-01-27 at 06:21 -0800, Almad wrote: > On Jan 26, 1:19 am, Russell Keith-Magee <freakboy3...@gmail.com> > wrote: > > On Sun, Jan 25, 2009 at 10:45 PM,Almad<b...@almad.net> wrote: > > > 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. > > No, case we're talking about is a test that calls one view multiple > times in a row - and that is enough to have a problem with dev server.
Perhaps you could show some simplified example code? I have at least a few dozen tests that do this and they don't have any problem. Serial requests work fine with the development server. I know of plenty of other people doing similar things. [...] > OK, if it's not meant for serious development and testing work, I > guess it's OK then. Depends on your definition of "serious". Given the thousands of Django applications that have, at least, started out using the development server, your claim seems a little vacuous. > (I'd just say that opitional multithreading contained in 10-line long > patch is not so complicated) > > > 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". > > OK, if community is expected to ignore 'do not use this option for > production or you'll be banned from all our communication channels on > first complaint', I guess nothing can be done. And if somebody had said that, you *might* even be have a semi-valid complaint. What colour is the sky in your world? The "community" is not expected to ignore the 'do not use in production'. They're expected to read it and take it to heart. Nothing has ever been said about banning. Russell pointed out something that has been mentioned multiple times in the past: the development server has a well-defined role to play and the step-up from there to using other servers when circumstances require is incredibly minimal. Graham's blog post, given earlier in the thread, about how to use mod_wsgi is just one example of that. Once we expand the scope of the development server, it *will* be used in further unintended ways and we *will* be obliged to maintain it, including issuing security fixes and the like. You might well have some reduced outlook on the time commitment involved there, which is fine, since you aren't one of the people on the hook for things like that in Django. The group of core maintainers have decided to devote time elsewhere. > > i guess PHP users are our target group. > > > 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. > > Yes, that's the only type of view affected. And some tests... > > > 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. > > Well, after I fall into small group of users that do some automatized > acceptance testing (and thus require, like, Selenium) and discovered > that things looks like working after I lobotomized Django and replaced > it with CherryPy, I'm now satisfied. When you could have just used mod_wsgi, or CherryPy's WSGI server or any number of other things. Nice over-reaction there. Note, also, that there's a ticket open in Trac to add some extra bits and pieces for allowing Selenium integration with Django's test framework. That would also give you some idea of the direction things could go. This was a very disappointing mail to read. Whilst I realise you might well be frustrated, the tone is simply insulting to the amount of work that has gone into developing and supporting Django and tries to inflate whatever problem it is that you're having (which hasn't been explained in detail) way out of proportion. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
