Re: i am using angular2 as frontend and django as backend. i am getting error zone already loaded.

2017-07-18 Thread Александр Христюхин (roboslone) 
You shouldn't use this mailing list for that, try django-users@ instead. Also, 
your problem is probably not related to Django,

> On 18 Jul 2017, at 09:24, Shivam Khare  wrote:
> 
> Uncaught Error: Zone already loaded.
> at :25:15
> at :638:3
> at Zone.assertZonePatched (:11:6)
> at :12:2
> at HTMLHeadElement.HTMLElement.appendChild (:309:45)
> at p (jquery-3.1.1.min.js:2)
> at Function.globalEval (jquery-3.1.1.min.js:2)
> at text script (jquery-3.1.1.min.js:4)
> at Nb (jquery-3.1.1.min.js:4)
> at A (jquery-3.1.1.min.js:4)
> 
> apart from this browser keeps on reloading. same error showing multiple time 
> when i open console through ctrl+shift+j in chrome.
> 
> -- 
> 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/1e3da2a6-2bd3-4569-a537-3461bb69fd6e%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/19A623AC-42EF-46DC-94F1-204A547F794E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.0 Python version support (Python 3.6+ only?)

2017-01-07 Thread roboslone 
> I do not think this matters, first off there is no commitment from our side 
> on type hinting or anything. We do not have any DEP or something related and 
> didn't even discuss if we actually want type hinting. Personally I am kinda 
> against it anyways, since it clutters the code for not much gain. So if we 
> were to do it, I would prefer stub files anyways, in which case we won't 
> depend on any python version as far as I understood that.

As Django user, I have to say type hinting would help a lot to understand how 
things work in Django without looking at docs. It could save a lot of time for 
beginners, too. Also I have to mention, that PyCharm (which is the most popular 
IDE for Python, I believe) has support for type hinting and could help you 
avoid many problems before even firing up a server.

In my opinion not adding type hints in Django 2.0 would be a mistake.

> "Django 2.0 will be the last version of Django to support Python 3.4. This 
> allows those running older operating systems with Python 3.4 (such as Ubuntu 
> 14.04 and CentOS 6) to use the latest version of Django for an additional 
> eight months. If you don't intend to upgrade to a system with Python 3.5 or 
> later by the end of security updates for Django 2.0 in April 2019, stick with 
> Django 1.11 LTS which is supported until April 2020."


As to Python 3.4 support, Django 1.11 will be LTS and most projects written 
with Django <=1.10 will probably stay on LTS version. Using Django 2.0 in 
existing project would require rewriting some bits anyway (correct me if I'm 
wrong), so there's really not much point in sticking to Python 3.4/3.5 in my 
opinion. If you're rewriting your code to use new version of Django, you could 
as well use new version of Python. Isn't it the whole point of major release?

Sticking to 3.6 would allow using format strings, and that would greatly 
increase readability (looking at %-strings here). To be honest, using 
str.format on string with many variables can hurt readability almost as much as 
% does. Also, variable annotation only appeared in 3.6, so supporting Python 
3.5 an older would mean that variable annotation is only possible using 
comments (which is not necessarily a bad thing, tough it has some downsides as 
pointed out in PEP-526).

I have to add, that nowadays deploying python applications with desired version 
of Python is fairly easy. One could use relocatable virtualenvs, Docker 
containers and so on. So even if you're on an outdated distro (or something 
like RHEL, that wouldn't get new python version in ages, probably) and your OS 
is stuck with older version of Python, your application doesn't have to be.

Since there're a lot of Django users out there who aren't subscribed to this 
mailing list, I suggest to sum up this discussion in a blog post and let users 
vote. I believe a big "Help decide Django 2.0 fate" button on djangoproject.com 
would attract much more attention to the issue. Maybe most of Django users are 
ready to migrate to Python 3.6 when they switch to Django 2.0 (probably not, 
but who knows) and developers could start enjoying new Python features a year 
or two earlier.

P.S. Please treat everything above as a personal opinion, I'm probably wrong 
about some things. And sorry for a bad English, it's not my native language.

> On 7 Jan 2017, at 19:48, Tim Graham  wrote:
> 
> Daniele, here's my try at being more concrete than "It seems reasonable" and 
> "decent ledge of overlap". Let me know if you meant something different!
> 
> "Django 2.0 will be the last version of Django to support Python 3.4. This 
> allows those running older operating systems with Python 3.4 (such as Ubuntu 
> 14.04 and CentOS 6) to use the latest version of Django for an additional 
> eight months. If you don't intend to upgrade to a system with Python 3.5 or 
> later by the end of security updates for Django 2.0 in April 2019, stick with 
> Django 1.11 LTS which is supported until April 2020."
> 
> I'd rather not allow Python 3.4 users to strand themselves on Django 2.0 when 
> sticking with 1.11 would provide longer security support (lesson learned from 
> Python 2.6 users stranded on Django 1.6), but hopefully documenting this 
> danger will help prevent that this time around.
> 
> On Saturday, January 7, 2017 at 6:30:23 AM UTC-5, Daniele Procida wrote:
> On Sat, Jan 7, 2017, Florian Apolloner  
> wrote: 
> 
> >Not sure on how we'd put that into text, but something along the lines of 
> >"we will support 3.4+ as long as feasible for us to do so" -- though I do 
> >understand that this is like the same as saying: "We'll just support what 
> >we want, how long we want" :D 
> 
> For the purposes of being reassuring, it needs to be concrete, otherwise 
> we're just moving people's doubt and uncertainty around! 
> 
> 
> It seems reasonable that Django 2.0 should continue to support Python 3.4, 
> and that Django 2.1 should not. That provides

Re: No 'Content-Type' header in response

2016-12-26 Thread roboslone 
Okay, so I've submitted a pull-request 
<https://github.com/django/django/pull/7746> resolving this issue. But tests 
for timesince, timeuntil are still broken. I believe #27637 
<https://code.djangoproject.com/ticket/27637> (PR 
<https://github.com/django/django/pull/7744>) fixes them.
Do I need to do anything to fix those tests in my PR? Merging felixmm's PR in 
my fork doesn't seem right.

> On 27 Dec 2016, at 06:36, roboslone <robosl...@gmail.com> wrote:
> 
> Oh, nevermind. Instructions are attached to the ticket. I'll start to work on 
> this.
> 
>> On 27 Dec 2016, at 06:33, roboslone <robosl...@gmail.com 
>> <mailto:robosl...@gmail.com>> wrote:
>> 
>> So how can I help resolve this? Should I just fork Django on GitHub and make 
>> a pull-request?
>> 
>>> On 26 Dec 2016, at 15:45, Curtis Maloney <cur...@tinbrain.net 
>>> <mailto:cur...@tinbrain.net>> wrote:
>>> 
>>> From what I can see in the rfc, it is permitted but not required.
>>> 
>>> Only a body in a 204 response is proscribed.
>>> 
>>> Any metadata (I.e. headers) are about the resource just accessed... So a 
>>> Content-Type would, IMHO, be acceptable but not essential.
>>> 
>>> 
>>> 
>>> On 26 December 2016 9:47:02 PM AEDT, roboslone <robosl...@gmail.com 
>>> <mailto:robosl...@gmail.com>> wrote:
>>> Thanks, that was an old setting in Mail.app =/
>>> 
>>> I've made a pull-request to DRF: 
>>> https://github.com/tomchristie/django-rest-framework/pull/4768 
>>> <https://github.com/tomchristie/django-rest-framework/pull/4768>
>>> But it seems to me that fixing it in Django would be more appropriate.
>>> 
>>> On the subject of Content-Type header with no response body, seems there's 
>>> no convention about it, I've found different opinions on the web. The only 
>>> thing I'm sure about is that putting None in that header is a bad idea.
>>> 
>>>> On 26 Dec 2016, at 13:24, Adam Johnson <m...@adamj.eu 
>>>> <mailto:m...@adamj.eu>> wrote:
>>>> 
>>>> Hi GMail! (you might want to fix your name used on google groups, I had 
>>>> the same problem ;) )
>>>> 
>>>> This seems to be a legitimate bug in the __repr__ to me - SO informs me 
>>>> that DRF is correct in not defining a Content-Type for a 204 as it has no 
>>>> body: 
>>>> https://stackoverflow.com/questions/21029351/what-content-type-should-a-204-no-response-use
>>>>  
>>>> <https://stackoverflow.com/questions/21029351/what-content-type-should-a-204-no-response-use>
>>>> 
>>>> I created a ticket: https://code.djangoproject.com/ticket/27640 
>>>> <https://code.djangoproject.com/ticket/27640> . If you want to try fix it 
>>>> there's a great contribution guide at 
>>>> https://docs.djangoproject.com/en/dev/internals/contributing/ 
>>>> <https://docs.djangoproject.com/en/dev/internals/contributing/> . I think 
>>>> using str.format would be acceptable, but the dict subclass sounds more 
>>>> complicated than just doing self.get('Content-Type', '') :)
>>>> 
>>>> On 26 December 2016 at 05:57, GMail <robosl...@gmail.com 
>>>> <mailto:robosl...@gmail.com>> wrote:
>>>> 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` 
>>&

Re: No 'Content-Type' header in response

2016-12-26 Thread roboslone 
Oh, nevermind. Instructions are attached to the ticket. I'll start to work on 
this.

> On 27 Dec 2016, at 06:33, roboslone <robosl...@gmail.com> wrote:
> 
> So how can I help resolve this? Should I just fork Django on GitHub and make 
> a pull-request?
> 
>> On 26 Dec 2016, at 15:45, Curtis Maloney <cur...@tinbrain.net 
>> <mailto:cur...@tinbrain.net>> wrote:
>> 
>> From what I can see in the rfc, it is permitted but not required.
>> 
>> Only a body in a 204 response is proscribed.
>> 
>> Any metadata (I.e. headers) are about the resource just accessed... So a 
>> Content-Type would, IMHO, be acceptable but not essential.
>> 
>> 
>> 
>> On 26 December 2016 9:47:02 PM AEDT, roboslone <robosl...@gmail.com 
>> <mailto:robosl...@gmail.com>> wrote:
>> Thanks, that was an old setting in Mail.app =/
>> 
>> I've made a pull-request to DRF: 
>> https://github.com/tomchristie/django-rest-framework/pull/4768 
>> <https://github.com/tomchristie/django-rest-framework/pull/4768>
>> But it seems to me that fixing it in Django would be more appropriate.
>> 
>> On the subject of Content-Type header with no response body, seems there's 
>> no convention about it, I've found different opinions on the web. The only 
>> thing I'm sure about is that putting None in that header is a bad idea.
>> 
>>> On 26 Dec 2016, at 13:24, Adam Johnson <m...@adamj.eu 
>>> <mailto:m...@adamj.eu>> wrote:
>>> 
>>> Hi GMail! (you might want to fix your name used on google groups, I had the 
>>> same problem ;) )
>>> 
>>> This seems to be a legitimate bug in the __repr__ to me - SO informs me 
>>> that DRF is correct in not defining a Content-Type for a 204 as it has no 
>>> body: 
>>> https://stackoverflow.com/questions/21029351/what-content-type-should-a-204-no-response-use
>>>  
>>> <https://stackoverflow.com/questions/21029351/what-content-type-should-a-204-no-response-use>
>>> 
>>> I created a ticket: https://code.djangoproject.com/ticket/27640 
>>> <https://code.djangoproject.com/ticket/27640> . If you want to try fix it 
>>> there's a great contribution guide at 
>>> https://docs.djangoproject.com/en/dev/internals/contributing/ 
>>> <https://docs.djangoproject.com/en/dev/internals/contributing/> . I think 
>>> using str.format would be acceptable, but the dict subclass sounds more 
>>> complicated than just doing self.get('Content-Type', '') :)
>>> 
>>> On 26 December 2016 at 05:57, GMail <robosl...@gmail.com 
>>> <mailto:robosl...@gmail.com>> wrote:
>>> 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 
>>> <mailto:django-developers%2bunsubscr...@googlegroups.com>.
>>> To post to this group, send email to django-developers@googlegroups.com 
>>> <mailto:django-developers@googlegroups.com>.
>>> Visit this group at https://groups.google.com/group/django-developers 
>>> <https://groups.google.com/group/django-developers>.
>>> To view this discussion on the web visit 
>>> https://groups.google.com

Re: No 'Content-Type' header in response

2016-12-26 Thread roboslone 
So how can I help resolve this? Should I just fork Django on GitHub and make a 
pull-request?

> On 26 Dec 2016, at 15:45, Curtis Maloney <cur...@tinbrain.net> wrote:
> 
> From what I can see in the rfc, it is permitted but not required.
> 
> Only a body in a 204 response is proscribed.
> 
> Any metadata (I.e. headers) are about the resource just accessed... So a 
> Content-Type would, IMHO, be acceptable but not essential.
> 
> 
> 
> On 26 December 2016 9:47:02 PM AEDT, roboslone <robosl...@gmail.com> wrote:
> Thanks, that was an old setting in Mail.app =/
> 
> I've made a pull-request to DRF: 
> https://github.com/tomchristie/django-rest-framework/pull/4768 
> <https://github.com/tomchristie/django-rest-framework/pull/4768>
> But it seems to me that fixing it in Django would be more appropriate.
> 
> On the subject of Content-Type header with no response body, seems there's no 
> convention about it, I've found different opinions on the web. The only thing 
> I'm sure about is that putting None in that header is a bad idea.
> 
>> On 26 Dec 2016, at 13:24, Adam Johnson <m...@adamj.eu 
>> <mailto:m...@adamj.eu>> wrote:
>> 
>> Hi GMail! (you might want to fix your name used on google groups, I had the 
>> same problem ;) )
>> 
>> This seems to be a legitimate bug in the __repr__ to me - SO informs me that 
>> DRF is correct in not defining a Content-Type for a 204 as it has no body: 
>> https://stackoverflow.com/questions/21029351/what-content-type-should-a-204-no-response-use
>>  
>> <https://stackoverflow.com/questions/21029351/what-content-type-should-a-204-no-response-use>
>> 
>> I created a ticket: https://code.djangoproject.com/ticket/27640 
>> <https://code.djangoproject.com/ticket/27640> . If you want to try fix it 
>> there's a great contribution guide at 
>> https://docs.djangoproject.com/en/dev/internals/contributing/ 
>> <https://docs.djangoproject.com/en/dev/internals/contributing/> . I think 
>> using str.format would be acceptable, but the dict subclass sounds more 
>> complicated than just doing self.get('Content-Type', '') :)
>> 
>> On 26 December 2016 at 05:57, GMail <robosl...@gmail.com 
>> <mailto:robosl...@gmail.com>> wrote:
>> 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 
>> <mailto:django-developers%2bunsubscr...@googlegroups.com>.
>> To post to this group, send email to django-developers@googlegroups.com 
>> <mailto:django-developers@googlegroups.com>.
>> Visit this group at https://groups.google.com/group/django-developers 
>> <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
>>  
>> <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 
>> <https://groups.google.com/d/optout>.
>> 
>> 
>> 
>> -- 
>> Adam
>> 
>> -- 
>> 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

Re: No 'Content-Type' header in response

2016-12-26 Thread roboslone 
Thanks, that was an old setting in Mail.app =/

I've made a pull-request to DRF: 
https://github.com/tomchristie/django-rest-framework/pull/4768 

But it seems to me that fixing it in Django would be more appropriate.

On the subject of Content-Type header with no response body, seems there's no 
convention about it, I've found different opinions on the web. The only thing 
I'm sure about is that putting None in that header is a bad idea.

> On 26 Dec 2016, at 13:24, Adam Johnson  wrote:
> 
> Hi GMail! (you might want to fix your name used on google groups, I had the 
> same problem ;) )
> 
> This seems to be a legitimate bug in the __repr__ to me - SO informs me that 
> DRF is correct in not defining a Content-Type for a 204 as it has no body: 
> https://stackoverflow.com/questions/21029351/what-content-type-should-a-204-no-response-use
>  
> 
> 
> I created a ticket: https://code.djangoproject.com/ticket/27640 
>  . If you want to try fix it 
> there's a great contribution guide at 
> https://docs.djangoproject.com/en/dev/internals/contributing/ 
>  . I think 
> using str.format would be acceptable, but the dict subclass sounds more 
> complicated than just doing self.get('Content-Type', '') :)
> 
> On 26 December 2016 at 05:57, GMail  > wrote:
> 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 
> .
> 
> 
> 
> -- 
> Adam
> 
> -- 
> 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/CAMyDDM39qZj7fV-MvPX%2BtXvSNL9%2B80283Aa5P47uBh3D46Q8BQ%40mail.gmail.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

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

2016-08-24 Thread roboslone 
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 
> <http://docs.python-requests.org/en/master/user/advanced/#timeouts>), 
> 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.