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 empty
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 again... I
>> do agree there
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
> 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 o
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 again... I
do agree there is a shorter path to just applying Django's "fixes" to a
fork o
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 step. The common denom
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 server/
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,
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 trie
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
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 running.
11 matches
Mail list logo
