On 28 Led, 01:25, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Tue, Jan 27, 2009 at 11:21 PM, Almad <b...@almad.net> wrote: > Sorry, but my stress-induced fibritis can only take so much. As a > hint, if you ever find yourself in a position where you need to > apologize at the end of an email for the tone you've taken, it's > probably a good indicator that you need to go back and edit for tone.
That's certainly true and I'll try to do better next time. > As a further hint, using pejoratives in project naming - like, say, > "Sane Testing in Django" - isn't a good way to encourage others to > assist you. I don't consider "sane testing" to be pejorative, but I can change that. However, I'll be more glad if I can wipe the whole project by finding proper Django ways (or perhaps few Django patches) and do some integration. > I've explained the reasoning behind Django's decisions. I can only > assure you that I know many people that aren't affected by those > decisions, and are able to use Django's testing framework, as is, > without difficulty. Some of them are even able to use Selenium. I guess that then they are doing generic smoke tests, because they cannot use the xUnit infrastructure and setup database in pre-defined state? Or is there a simple way to do it, are there any hints around? > If you sit down and work through the problem, you will establish that > the consequences of those decisions aren't as widespread as you seem > to think. There is _exactly_ one limitation to Django'sdevelopment > server - _concurrent_ web requests. To be sure, this does impose > limitations, but as long as you don't need concurrent server requests, > you won't have any problems with a single-threaded server. Most web > pages can be adequately served by a number of _sequential_ web > requests. Either it's not entirely true, or I'm bad at reading sources and urllib2 do some concurrent requests without my knowledge. See #10117 (http://code.djangoproject.com/ticket/10117) for sample code. > I will also remind you that just because _you_ hit a given problem > every single day, doesn't mean that _everyone_ hits that problem every > single day. Such is the nature of esoteric problems. Looks like so. I have, however, > You will note that so far in this thread, you haven't actually > described your problem - just that amultithreadedserver is > apparently the only way to solve it. If you ever feel like describing > your problem (sans rhetoric) and working constructively towards a > solution, let me know. One of my biggest problems (that I, obviously mistakenly, considered widespread) is regression testing of digest-protected REST APIs. Test client is way around (plus it does not support digest, but as Django do not support it as well, I can't blame it), and I'd like to use some other software tools that cannot do whitebox, and urllib cannot be used due to bug #10117. I must say, however, that now with some integration things works for me and I'm not working on integration (as this relies on #2879 anyway, which was having patch shortly after creation, got ignored and now laying silently for two years as even mikeal got up for runtime patching). > Yours, > Russ Magee %-) Almad --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
