Re: Deprecate FCGI support in Django 1.7

2013-07-20 Thread Christian Schmitt
I would recommand to remove FastCGI. That's the thing i love with the Python Community. Remove depracted or obsolete things. The thing is, there are way more important things to do, than supporting a 'depracted' way to deploy. And it's really not that hard to get mod_wsgi with a httpd

Re: Deprecate FCGI support in Django 1.7

2013-07-20 Thread Some Developer
On 20/07/13 12:32, Christian Schmitt wrote: I would recommand to remove FastCGI. That's the thing i love with the Python Community. Remove depracted or obsolete things. The thing is, there are way more important things to do, than supporting a 'depracted' way to deploy. And it's really not that

Re: Deprecate FCGI support in Django 1.7

2013-07-20 Thread Some Developer
On 20/07/13 13:24, Christian Schmitt wrote: No FastCGI isn't a bad protocol. But it's not recommand to deploy Python Application's with FastCGI. FastCGI is good for deploying PHP or even sometimes Golang (but here, the plain Webserver is better). But! FastCGI is a low level protocol and WSGI

Re: Deprecate FCGI support in Django 1.7

2013-07-20 Thread Curtis Maloney
I'm more or less building atop flup as it is, however I plan to shed anything not related to FastCGI. For me it's a chance to get down and dirty with raw protocols again... I do agree there is a shorter path to just applying Django's "fixes" to a fork of flup. -- Curtis On 19 July 2013 22:14,

Re: Deprecate FCGI support in Django 1.7

2013-07-20 Thread Christian Schmitt
No FastCGI isn't a bad protocol. But it's not recommand to deploy Python Application's with FastCGI. FastCGI is good for deploying PHP or even sometimes Golang (but here, the plain Webserver is better). But! FastCGI is a low level protocol and WSGI tries to get rid of that. Flup is just a

Re: #20739 - Making LiveServerTestCase not depend on staticfiles?

2013-07-20 Thread Julien Phalip
Hi, On Jul 15, 2013, at 9:22 AM, Carl Meyer wrote: > On 07/14/2013 07:16 AM, Jannis Leidel wrote: >> Yeah, I can relate to that, it does to me, too. I think decoupling >> the file serving slightly from how the files got to the place they >> are served from, is a good first

Re: Deprecate FCGI support in Django 1.7

2013-07-20 Thread Juan Luis Boya
> If you really want to get down and dirty with raw protocols have you > considered an implementation that used epoll or kqueue for the > networking? Combined with nginx as the front end HTTP server it should > (theoretically) result in a huge increase in performance. > > Basing the work on

Re: Deprecate FCGI support in Django 1.7

2013-07-20 Thread Curtis Maloney
Juan, technically Django isn't a server at all... whether it's sync, async, multi-threaded, multi-process, or a mix of any of them is up to the wsgi publisher used. Take, for example, gunicorn, which can be any of the above, with options to plug in others when they're thought up. -- Curtis On

Re: Deprecate FCGI support in Django 1.7

2013-07-20 Thread Curtis Maloney
On 21 July 2013 02:30, Some Developer wrote: > On 20/07/2013 14:02, Curtis Maloney wrote: > >> I'm more or less building atop flup as it is, however I plan to shed >> anything not related to FastCGI. >> >> For me it's a chance to get down and dirty with raw protocols

Re: Confusion around generic views queryset cloning.

2013-07-20 Thread Tom Christie
Thanks both, the responses are very much appreciated. > It's the same issue as using mutable default arguments or attributes to a class. If someone is writing their own generic CBVs without understanding I don't see why the queryset case is any more problematic than having a class with an