Re: Simulating timeouts on client with django.test.client.Client

[GMail]

"Players" are backends (Django) and load balancer that proxies all user 
requests on one of the backends.
In my case load balancer has small backend timeout (default is 3 sec, 
preferable is 1 sec) and it will send the same request (with the same 
X-Request-Id header) to another backend after this small timeout.
Some requests may take a long time to process (well, longer than 1 sec), so 
backends should not try to process requests that are being processed by other 
backends (they actually return "HTTP 202 Accepted" instead).

For testing purposes I have '/slow/' view that takes exactly  
seconds to process.

What I want to do is this:
1. Use django.test.client.Client to send request with small timeout (like load 
balancer will do) and make assertion, that TimeoutError is raised.
2. Send same request again and make assertion, that backend responded with 
"HTTP 202 Accepted".
3. Wait for some time ( seconds to be sure, that request has been 
processed by first backend) and send same request again and make final 
assertion, that backend responded with "HTTP 200 OK".

In my case backends are synchronised through distributed cache, so it doesn't 
matter which backend accepts each request, response will be the same.

I do realise, that this can be accomplished by just firing up "manage.py 
runserver" and sending requests as real load balancer would do, but I think 
it's too much overhead for a simple test.

By "prototype" you mean pull-request to Django with django.test.client.Client 
that supports 'timeout' argument, right?


> On 24 Aug 2016, at 16:44, Shai Berger  wrote:
> 
> On Wednesday 24 August 2016 14:33:34 Александр Христюхин wrote:
>> Actually network is not an issue here. I'm using locks in distributed cache
>> to manage requests between backends and that's what I want to test. In this
>> case calling Django directly is okay.
>> 
> 
> I am sorry, then; it seems I have misunderstood your needs. Now I am quite 
> unsure about who are the "players" in your use-case -- who makes requests to 
> whom, what kind of requests, which side of these requests is supposed to time 
> out, and how the other side is supposed to discover the problem.
> 
> It may be helpful to do as Tim suggested and write a prototype, just so we 
> get 
> the details in a clear and unambiguous way.
> 
> HTH,
>   Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/A4738F0B-70AD-4079-9142-F6DA61E8D0AA%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Simulating timeouts on client with django.test.client.Client

[GMail]

I didn't try LiveServerTestCase yet (and to be honest never heard of it 
before), I'll give it a try. Thanks!


> On 24 Aug 2016, at 17:19, Shai Berger  wrote:
> 
> Yes, the prototype I mentioned is a PR against Django, except that if it is 
> intended to clarify the request rather than supply it, it doesn't have to be 
> full -- e.g. it doesn't need tests or documentation untill we decide we want 
> the feature in.
> 
> But before you go there -- isn't LiveServerTestCase (which starts a server 
> you 
> can send requests to) a better answer to your needs?
> 
> On Wednesday 24 August 2016 17:10:42 GMail wrote:
>> "Players" are backends (Django) and load balancer that proxies all user
>> requests on one of the backends. In my case load balancer has small
>> backend timeout (default is 3 sec, preferable is 1 sec) and it will send
>> the same request (with the same X-Request-Id header) to another backend
>> after this small timeout. Some requests may take a long time to process
>> (well, longer than 1 sec), so backends should not try to process requests
>> that are being processed by other backends (they actually return "HTTP 202
>> Accepted" instead).
>> 
>> For testing purposes I have '/slow/' view that takes exactly 
>> seconds to process.
>> 
>> What I want to do is this:
>> 1. Use django.test.client.Client to send request with small timeout (like
>> load balancer will do) and make assertion, that TimeoutError is raised. 2.
>> Send same request again and make assertion, that backend responded with
>> "HTTP 202 Accepted". 3. Wait for some time ( seconds to be sure,
>> that request has been processed by first backend) and send same request
>> again and make final assertion, that backend responded with "HTTP 200 OK".
>> 
>> In my case backends are synchronised through distributed cache, so it
>> doesn't matter which backend accepts each request, response will be the
>> same.
>> 
>> I do realise, that this can be accomplished by just firing up "manage.py
>> runserver" and sending requests as real load balancer would do, but I
>> think it's too much overhead for a simple test.
>> 
>> By "prototype" you mean pull-request to Django with
>> django.test.client.Client that supports 'timeout' argument, right?
>> 
>>> On 24 Aug 2016, at 16:44, Shai Berger  wrote:
>>> 
>>> On Wednesday 24 August 2016 14:33:34 Александр Христюхин wrote:
>>>> Actually network is not an issue here. I'm using locks in distributed
>>>> cache to manage requests between backends and that's what I want to
>>>> test. In this case calling Django directly is okay.
>>> 
>>> I am sorry, then; it seems I have misunderstood your needs. Now I am
>>> quite unsure about who are the "players" in your use-case -- who makes
>>> requests to whom, what kind of requests, which side of these requests is
>>> supposed to time out, and how the other side is supposed to discover the
>>> problem.
>>> 
>>> It may be helpful to do as Tim suggested and write a prototype, just so
>>> we get the details in a clear and unambiguous way.
>>> 
>>> HTH,
>>> 
>>> Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/441020A1-BF34-4675-BD8B-1F20D43B619E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Simulating timeouts on client with django.test.client.Client

[GMail]

So I've tried LiveServerTestCase and it seems that live server is 
single-threaded.

If client timeout is 5 seconds, then LiveServerTestCase works fine for slow 
requests, that take from 1 to 9 seconds to process. Second try will send 
request to the same thread and client will get TimeoutError instead of "HTTP 
202 Accepted" (because thread is busy processing first request).

I didn't find any information about how to start live server with multiple 
threads in Django docs or LiveServerTestCase code, is that even possible?

> On 24 Aug 2016, at 17:26, GMail  wrote:
> 
> I didn't try LiveServerTestCase yet (and to be honest never heard of it 
> before), I'll give it a try. Thanks!
> 
> 
>> On 24 Aug 2016, at 17:19, Shai Berger  wrote:
>> 
>> Yes, the prototype I mentioned is a PR against Django, except that if it is 
>> intended to clarify the request rather than supply it, it doesn't have to be 
>> full -- e.g. it doesn't need tests or documentation untill we decide we want 
>> the feature in.
>> 
>> But before you go there -- isn't LiveServerTestCase (which starts a server 
>> you 
>> can send requests to) a better answer to your needs?
>> 
>> On Wednesday 24 August 2016 17:10:42 GMail wrote:
>>> "Players" are backends (Django) and load balancer that proxies all user
>>> requests on one of the backends. In my case load balancer has small
>>> backend timeout (default is 3 sec, preferable is 1 sec) and it will send
>>> the same request (with the same X-Request-Id header) to another backend
>>> after this small timeout. Some requests may take a long time to process
>>> (well, longer than 1 sec), so backends should not try to process requests
>>> that are being processed by other backends (they actually return "HTTP 202
>>> Accepted" instead).
>>> 
>>> For testing purposes I have '/slow/' view that takes exactly 
>>> seconds to process.
>>> 
>>> What I want to do is this:
>>> 1. Use django.test.client.Client to send request with small timeout (like
>>> load balancer will do) and make assertion, that TimeoutError is raised. 2.
>>> Send same request again and make assertion, that backend responded with
>>> "HTTP 202 Accepted". 3. Wait for some time ( seconds to be sure,
>>> that request has been processed by first backend) and send same request
>>> again and make final assertion, that backend responded with "HTTP 200 OK".
>>> 
>>> In my case backends are synchronised through distributed cache, so it
>>> doesn't matter which backend accepts each request, response will be the
>>> same.
>>> 
>>> I do realise, that this can be accomplished by just firing up "manage.py
>>> runserver" and sending requests as real load balancer would do, but I
>>> think it's too much overhead for a simple test.
>>> 
>>> By "prototype" you mean pull-request to Django with
>>> django.test.client.Client that supports 'timeout' argument, right?
>>> 
>>>> On 24 Aug 2016, at 16:44, Shai Berger  wrote:
>>>> 
>>>> On Wednesday 24 August 2016 14:33:34 Александр Христюхин wrote:
>>>>> Actually network is not an issue here. I'm using locks in distributed
>>>>> cache to manage requests between backends and that's what I want to
>>>>> test. In this case calling Django directly is okay.
>>>> 
>>>> I am sorry, then; it seems I have misunderstood your needs. Now I am
>>>> quite unsure about who are the "players" in your use-case -- who makes
>>>> requests to whom, what kind of requests, which side of these requests is
>>>> supposed to time out, and how the other side is supposed to discover the
>>>> problem.
>>>> 
>>>> It may be helpful to do as Tim suggested and write a prototype, just so
>>>> we get the details in a clear and unambiguous way.
>>>> 
>>>> HTH,
>>>> 
>>>>Shai.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CE62BBC5-DF10-4395-BCB4-AEDF25AE9591%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Simulating timeouts on client with django.test.client.Client

[GMail]

I found this ticket about same issue: 
https://code.djangoproject.com/ticket/20238 
<https://code.djangoproject.com/ticket/20238>
It was closed 2 years ago and one of the reasons is that use case was 
considered "somewhat fictional". I personally think my case is very real :)

I'm thinking about using 'manage.py runserver' manually, because it seems it 
would do the same thing as LiveServerTestCase and also server with multiple 
threads. But that solution doesn't seem right to me.


> On 24 Aug 2016, at 21:20, GMail  wrote:
> 
> So I've tried LiveServerTestCase and it seems that live server is 
> single-threaded.
> 
> If client timeout is 5 seconds, then LiveServerTestCase works fine for slow 
> requests, that take from 1 to 9 seconds to process. Second try will send 
> request to the same thread and client will get TimeoutError instead of "HTTP 
> 202 Accepted" (because thread is busy processing first request).
> 
> I didn't find any information about how to start live server with multiple 
> threads in Django docs or LiveServerTestCase code, is that even possible?
> 
>> On 24 Aug 2016, at 17:26, GMail  wrote:
>> 
>> I didn't try LiveServerTestCase yet (and to be honest never heard of it 
>> before), I'll give it a try. Thanks!
>> 
>> 
>>> On 24 Aug 2016, at 17:19, Shai Berger  wrote:
>>> 
>>> Yes, the prototype I mentioned is a PR against Django, except that if it is 
>>> intended to clarify the request rather than supply it, it doesn't have to 
>>> be 
>>> full -- e.g. it doesn't need tests or documentation untill we decide we 
>>> want 
>>> the feature in.
>>> 
>>> But before you go there -- isn't LiveServerTestCase (which starts a server 
>>> you 
>>> can send requests to) a better answer to your needs?
>>> 
>>> On Wednesday 24 August 2016 17:10:42 GMail wrote:
>>>> "Players" are backends (Django) and load balancer that proxies all user
>>>> requests on one of the backends. In my case load balancer has small
>>>> backend timeout (default is 3 sec, preferable is 1 sec) and it will send
>>>> the same request (with the same X-Request-Id header) to another backend
>>>> after this small timeout. Some requests may take a long time to process
>>>> (well, longer than 1 sec), so backends should not try to process requests
>>>> that are being processed by other backends (they actually return "HTTP 202
>>>> Accepted" instead).
>>>> 
>>>> For testing purposes I have '/slow/' view that takes exactly 
>>>> seconds to process.
>>>> 
>>>> What I want to do is this:
>>>> 1. Use django.test.client.Client to send request with small timeout (like
>>>> load balancer will do) and make assertion, that TimeoutError is raised. 2.
>>>> Send same request again and make assertion, that backend responded with
>>>> "HTTP 202 Accepted". 3. Wait for some time ( seconds to be sure,
>>>> that request has been processed by first backend) and send same request
>>>> again and make final assertion, that backend responded with "HTTP 200 OK".
>>>> 
>>>> In my case backends are synchronised through distributed cache, so it
>>>> doesn't matter which backend accepts each request, response will be the
>>>> same.
>>>> 
>>>> I do realise, that this can be accomplished by just firing up "manage.py
>>>> runserver" and sending requests as real load balancer would do, but I
>>>> think it's too much overhead for a simple test.
>>>> 
>>>> By "prototype" you mean pull-request to Django with
>>>> django.test.client.Client that supports 'timeout' argument, right?
>>>> 
>>>>> On 24 Aug 2016, at 16:44, Shai Berger  wrote:
>>>>> 
>>>>> On Wednesday 24 August 2016 14:33:34 Александр Христюхин wrote:
>>>>>> Actually network is not an issue here. I'm using locks in distributed
>>>>>> cache to manage requests between backends and that's what I want to
>>>>>> test. In this case calling Django directly is okay.
>>>>> 
>>>>> I am sorry, then; it seems I have misunderstood your needs. Now I am
>>>>> quite unsure about who are the "players" in your use-case -- who makes
>>>>> requests to whom, what kind of requests, which side of these requests is
>>>>> supposed to time out, and how the other side is supposed to discover the
>>>>> problem.
>>>>> 
>>>>> It may be helpful to do as Tim suggested and write a prototype, just so
>>>>> we get the details in a clear and unambiguous way.
>>>>> 
>>>>> HTH,
>>>>> 
>>>>>   Shai.
>> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8A874FAC-70B0-4FA1-A38D-DAFCA9B1C418%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Simulating timeouts on client with django.test.client.Client

[GMail]

Wow, that was a quick response!
Tim, is there a way for me to join the discussion? Is there another mail thread?

> On 24 Aug 2016, at 21:36, Tim Graham  wrote:
> 
> multithreading support has been proposed a couple times but it hasn't passed 
> the discussion stage yet.
> 
> https://code.djangoproject.com/ticket/20238
> https://code.djangoproject.com/ticket/25970
> 
> On Wednesday, August 24, 2016 at 2:21:07 PM UTC-4, roboslone wrote:
> So I've tried LiveServerTestCase and it seems that live server is 
> single-threaded. 
> 
> If client timeout is 5 seconds, then LiveServerTestCase works fine for slow 
> requests, that take from 1 to 9 seconds to process. Second try will send 
> request to the same thread and client will get TimeoutError instead of "HTTP 
> 202 Accepted" (because thread is busy processing first request). 
> 
> I didn't find any information about how to start live server with multiple 
> threads in Django docs or LiveServerTestCase code, is that even possible? 
> 
> > On 24 Aug 2016, at 17:26, GMail > wrote: 
> > 
> > I didn't try LiveServerTestCase yet (and to be honest never heard of it 
> > before), I'll give it a try. Thanks! 
> > 
> > 
> >> On 24 Aug 2016, at 17:19, Shai Berger > 
> >> wrote: 
> >> 
> >> Yes, the prototype I mentioned is a PR against Django, except that if it 
> >> is 
> >> intended to clarify the request rather than supply it, it doesn't have to 
> >> be 
> >> full -- e.g. it doesn't need tests or documentation untill we decide we 
> >> want 
> >> the feature in. 
> >> 
> >> But before you go there -- isn't LiveServerTestCase (which starts a server 
> >> you 
> >> can send requests to) a better answer to your needs? 
> >> 
> >> On Wednesday 24 August 2016 17:10:42 GMail wrote: 
> >>> "Players" are backends (Django) and load balancer that proxies all user 
> >>> requests on one of the backends. In my case load balancer has small 
> >>> backend timeout (default is 3 sec, preferable is 1 sec) and it will send 
> >>> the same request (with the same X-Request-Id header) to another backend 
> >>> after this small timeout. Some requests may take a long time to process 
> >>> (well, longer than 1 sec), so backends should not try to process requests 
> >>> that are being processed by other backends (they actually return "HTTP 
> >>> 202 
> >>> Accepted" instead). 
> >>> 
> >>> For testing purposes I have '/slow/' view that takes exactly  
> >>> seconds to process. 
> >>> 
> >>> What I want to do is this: 
> >>> 1. Use django.test.client.Client to send request with small timeout (like 
> >>> load balancer will do) and make assertion, that TimeoutError is raised. 
> >>> 2. 
> >>> Send same request again and make assertion, that backend responded with 
> >>> "HTTP 202 Accepted". 3. Wait for some time ( seconds to be sure, 
> >>> that request has been processed by first backend) and send same request 
> >>> again and make final assertion, that backend responded with "HTTP 200 
> >>> OK". 
> >>> 
> >>> In my case backends are synchronised through distributed cache, so it 
> >>> doesn't matter which backend accepts each request, response will be the 
> >>> same. 
> >>> 
> >>> I do realise, that this can be accomplished by just firing up "manage.py 
> >>> runserver" and sending requests as real load balancer would do, but I 
> >>> think it's too much overhead for a simple test. 
> >>> 
> >>> By "prototype" you mean pull-request to Django with 
> >>> django.test.client.Client that supports 'timeout' argument, right? 
> >>> 
> >>>> On 24 Aug 2016, at 16:44, Shai Berger > 
> >>>> wrote: 
> >>>> 
> >>>> On Wednesday 24 August 2016 14:33:34 Александр Христюхин wrote: 
> >>>>> Actually network is not an issue here. I'm using locks in distributed 
> >>>>> cache to manage requests between backends and that's what I want to 
> >>>>> test. In this case calling Django directly is okay. 
> >>>> 
> >>>> I am sorry, then; it seems I have misunderstood your needs. Now I am 
> >>>> quite unsure about who are the "players" in your use-

Re: Simulating timeouts on client with django.test.client.Client

[GMail]

I've actually tried adding ThreadingMixIn to WSGIServer and it worked like a 
charm in my case.
Here's the code I added: 

from django.test.testcases import LiveServerThread, QuietWSGIRequestHandler
from django.core.servers.basehttp import WSGIServer
from socketserver import ThreadingMixIn

class ThreadedWSGIServer(ThreadingMixIn, WSGIServer):
pass


class ThreadedLiveServerThread(LiveServerThread):
def _create_server(self, port):
return ThreadedWSGIServer((self.host, port), QuietWSGIRequestHandler)


class ThreadedLiveServerTestCase(LiveServerTestCase):
@classmethod
def _create_server_thread(cls, host, possible_ports, connections_override):
return ThreadedLiveServerThread(
host,
possible_ports,
cls.static_handler,
connections_override=connections_override,
)

(just in case, same on pastebin: http://pastebin.com/wTBCWQKJ 
)


> On 24 Aug 2016, at 21:46, roboslone  wrote:
> 
> In answer ti "Any idea how complex the patch would be?" in 
> https://code.djangoproject.com/ticket/25970#comment:2 I think using 
> socketserver.ThreadingMixin with django.core.servers.WSGIServer would do the 
> job. Not completely sure about consequences though...
> 
> вторник, 23 августа 2016 г., 19:59:40 UTC+3 пользователь roboslone написал:
> Hi!
> 
> I'm trying to simulate timeouts on client to test my app's behaviour with 
> requests, that take too much time. I want to use Django's test client for 
> that and supply timeout arg for each request (like in requests 
> ), but 
> django.test.client.Client doesn't support timeouts.
> 
> Here's a ticket about that: https://code.djangoproject.com/ticket/27112 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to django-developers@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/382280b3-2132-47d5-a051-d47c18fda646%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/B6E27DEA-2F99-4880-8B3E-1EAAAE95DB11%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Struggling newbie

[GMail]

Could you provide you settings file?
I think it may be an error in settings.

> On 24 Aug 2016, at 23:12, jsjazzj...@gmail.com wrote:
> 
> I am running python3.4 with Django in virtualenv.  When I execute python 
> manage.py runserver I continue to get "sqlite3.NotSupportedError: URIs not 
> supported",  I have looked all around for posts that will point me to the 
> solution but have not located any to date. Can anyone provide me with clues 
> as to what I have messed up in the environment?
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to django-developers@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/fb917387-fe59-4e62-867e-bdaac7bd82ce%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/72EF151D-A89A-481D-BB7E-C28AA0A46B5D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature suggestion: Option to suppress system checks in commands

[GMail]

Hi, wouldn't it be easier to create special settings for cron? Something like 
that:


# myprj/settings/cron.py

from myprj.settings import *
SILENCED_SYSTEM_CHECKS = ...


And in cron:

... python manage.py  --settings=myprj.settings.cron

> On 30 Sep 2016, at 11:31, Vlastimil Zíma  wrote:
> 
> Hi everyone,
> 
> I'd suggest an options for all commands to suppress a defined system checks 
> when running a command. I know it is possible to defined 
> SILENCED_SYSTEM_CHECKS in settings, but that has impact of everything 
> including the check command itself. My point is to suppress system checks 
> mainly for cron jobs, so they don't report errors. I don't want to use 
> settings because I don't want to suppress checks for migrate and other 
> commands when deploying new version of application.
> 
> I don't want to suppress checks for our commands either, since there is only 
> option to suppress checks completely.
> 
> Any support for this feature?
> 
> Regards,
> Vlastimil
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to django-developers@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/554d79d7-1485-46c7-8ecd-352422382c00%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/74001107-19D1-42A6-A6FB-41B3ABF7260E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature suggestion: Option to suppress system checks in commands

[GMail]

Hi, wouldn't it be easier to create special settings for cron? Something like 
that:


# myprj/settings/cron.py

from myprj.settings import *
SILENCED_SYSTEM_CHECKS = ...


And in cron:

... python manage.py  --settings=myprj.settings.cron

> On 30 Sep 2016, at 11:31, Vlastimil Zíma  > wrote:
> 
> Hi everyone,
> 
> I'd suggest an options for all commands to suppress a defined system checks 
> when running a command. I know it is possible to defined 
> SILENCED_SYSTEM_CHECKS in settings, but that has impact of everything 
> including the check command itself. My point is to suppress system checks 
> mainly for cron jobs, so they don't report errors. I don't want to use 
> settings because I don't want to suppress checks for migrate and other 
> commands when deploying new version of application.
> 
> I don't want to suppress checks for our commands either, since there is only 
> option to suppress checks completely.
> 
> Any support for this feature?
> 
> Regards,
> Vlastimil
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to django-developers@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/554d79d7-1485-46c7-8ecd-352422382c00%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/F2F20CB0-87C0-4583-AA60-27CC8E629516%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

HttpResponse.headers public property

[GMail]

Hi!

Is there a reason why HttpResponse doesn't have public 'headers' property?
I want to log all response headers in tests and don't want to access private 
'_headers' property.

Implementation is very simple and will prevent user from changing actual 
headers (if that was intended in the first place):

@property
def headers(self):
   return self._headers

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/B19D4F98-C6CD-419C-91A3-BE08EB2DA3C8%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: HttpResponse.headers public property

[GMail]

Given ticket is about HttpRequest headers, I was writing about HttpResponse. Am 
I missing something?

> On 8 Nov 2016, at 19:56, Tim Graham  wrote:
> 
> Here's an accepted ticket for the idea: 
> https://code.djangoproject.com/ticket/20147
> 
> It looks like there's rough consensus but a complete patch hasn't been 
> provided.
> 
> On Tuesday, November 8, 2016 at 11:04:53 AM UTC-5, roboslone wrote:
> Hi! 
> 
> Is there a reason why HttpResponse doesn't have public 'headers' property? 
> I want to log all response headers in tests and don't want to access private 
> '_headers' property. 
> 
> Implementation is very simple and will prevent user from changing actual 
> headers (if that was intended in the first place): 
> 
> @property 
> def headers(self): 
>return self._headers
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to django-developers@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/a4a67883-8726-46df-b863-f71d5b536e9b%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9DA56F87-2F88-4C0E-9BF5-B287E690A61C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: HttpResponse.headers public property

[GMail]

I didn't realise there's a difference. Personally, I think response.items() is 
better. Although it would be much nicer if headers could be accessed in the 
same way in HttpRequest and HttpResponse, so a ticket you posted earlier is 
quite relevant. In my opinion 'HEADERS' property (or lower-case 'headers', 
which seems better to me) is a good and obvious way to access headers in bot 
requests and responses.

Do you think I should post this thread's summary in #20147 
? Or maybe I should open similar 
ticket for HttpResponse only?

> On 8 Nov 2016, at 21:09, Tim Graham  wrote:
> 
> Sorry, I didn't read closely enough. I'm not sure about this. Do you really 
> want the raw _headers dict or something like response.items()?
> 
> >>> response.items()
> dict_values([('foo', 'bar'), ('Content-Type', 'text/html; charset=utf-8')])
> 
> >>> response._headers
> {'content-type': ('Content-Type', 'text/html; charset=utf-8'),
>  'foo': ('foo', 'bar')}
> 
> On Tuesday, November 8, 2016 at 12:08:49 PM UTC-5, roboslone wrote:
> Given ticket is about HttpRequest headers, I was writing about HttpResponse. 
> Am I missing something?
> 
>> On 8 Nov 2016, at 19:56, Tim Graham > wrote:
>> 
>> Here's an accepted ticket for the idea: 
>> https://code.djangoproject.com/ticket/20147 
>> 
>> 
>> It looks like there's rough consensus but a complete patch hasn't been 
>> provided.
>> 
>> On Tuesday, November 8, 2016 at 11:04:53 AM UTC-5, roboslone wrote:
>> Hi! 
>> 
>> Is there a reason why HttpResponse doesn't have public 'headers' property? 
>> I want to log all response headers in tests and don't want to access private 
>> '_headers' property. 
>> 
>> Implementation is very simple and will prevent user from changing actual 
>> headers (if that was intended in the first place): 
>> 
>> @property 
>> def headers(self): 
>>return self._headers
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/a4a67883-8726-46df-b863-f71d5b536e9b%40googlegroups.com
>>  
>> .
>> For more options, visit https://groups.google.com/d/optout 
>> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to django-developers@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/0347427c-44db-42c2-91a9-0f2669b44b89%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/82619A1B-8392-41BE-80B3-CF1A91439645%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

No 'Content-Type' header in response

[GMail]

Hi! I'm using Django 1.10.2 and Django-Rest-Framework 3.5.3.
I noticed, that HttpRequest.__repr__ method relies on 'Content-Type' header:


> class HttpResponse(HttpResponseBase):
> ...
> 
> def __repr__(self):
> return '<%(cls)s status_code=%(status_code)d, "%(content_type)s">' % {
> 'cls': self.__class__.__name__,
> 'status_code': self.status_code,
> 'content_type': self['Content-Type'],
> }


And after deleting an object in DRF sends empty response with HTTP204 and no 
'Content-Type' header. I was trying to log outgoing response and got KeyError 
here.

So I have two questions:
1. Is this intentional? Do all responses in Django have 'Content-Type' header 
and should DRF be aware of it?
2. Why not use `str.format` here? To avoid errors like this, `dict` subclass 
with `__missing__` method could be used.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/39F85D40-019C-411A-BCA7-402E338EA527%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Python 3 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

[Kok Hoor (gmail)]

I would like to say congrats and thanks to all those who have put in hard work 
on the Python 3 port. It is a very socially responsible thing to do, as django 
is one of the major open-source python framework, and will certainly act as 
encouragement for other python-based open-source to do the same (not to mention 
shut the mouth of critics who never stop mentioning django is still on python 2 
when 3 is already out ages ago) 

I personally know python via Google AppEngine, but never feel compelled to 
actually sacrifice my years of java / javascript knowledge to learn a new 
language! However django convinced me otherwise (love the 'for perfectionists 
with deadline' tagline!), and I believe a django on Python 3 will make a lot of 
difference.

Thanks guys and again, congrats for hard work done. Can't wait for django 1.5 
in python 3!

Regards,
Kok Hoor

Sent from my iPad

On Dec 11, 2011, at 12:47 AM, Luke Plant  wrote:

> On 09/12/11 20:26, Ram Rachum wrote:
>> In which Django release are we hoping to release this port? 1.4 or 1.5?
> 
> 1.4 is never going to happen. We are hoping to release a 1.4 alpha very
> soon, merging this work would be a major mistake at this point.
> 
> The patch requires lots of changes to the way things work. Many are
> small, but they impose some mental overhead (like using b() etc). We
> need *all* the core developers to get fully up to speed with these
> before we commit, otherwise we will introduce tons of bugs as we try to
> get 1.4 out of the door, even if all the tests pass at the moment.
> 
> The timing is very good for 1.5, however, so hopefully we can merge soon
> after the release of 1.4. Even then, I think 1.5 would be a "Python 3
> preview" i.e. we wouldn't promise the same level of support for Python 3
> as for Python 2.X.
> 
> Regards,
> 
> Luke
> 
> -- 
> Environmentalists are much too concerned with planet earth.  Their
> geocentric attitude prevents them from seeing the greater picture
> -- lots of planets are much worse off than earth is.
> 
> Luke Plant || http://lukeplant.me.uk/
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: drop Python 2.5 support in Django 1.5

[Kok Hoor (gmail)]

+1

Regards,
Kok HOOR

Sent from my iPad

On Dec 11, 2011, at 10:06 AM, Adrian Holovaty  wrote:

> On Sat, Dec 10, 2011 at 6:37 PM, Alex Gaynor  wrote:
>> 2.5 is EOL and no longer receiving security patches even, it is
>> *irresponsible* of us to support it (I claim).  ANyways +1
> 
> This is a very good reason I hadn't though of.
> 
> Anyway, looks like this is a plan! Excellent.
> 
> Adrian
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.