Re: Help!!

[Russell Keith-Magee]

Hi Chitra,

Django’s contribution guide is here:

https://docs.djangoproject.com/en/1.9/internals/contributing/

That gives you a step-by-step guide to the ways you can contribute, and how
to get started.

If you want some more specific guidelines or mentoring, you’ll need to tell
us a bit more about yourself - your experience, your areas of interest
(e.g., backend, frontend, etc). Once we know those details, it will be
easier to provide specific suggestions or suggest someone who might be in a
position to mentor you.

Yours
Russ Magee %-)

On Mon, Mar 21, 2016 at 1:31 AM, Chitra Sivakumar 
wrote:

> Hi ,
>
> I am new to open source and python, I am interested in doing open source
> contribution. It will be great !! if some mentor can help me getting
> started.
>
> regards
> chitra
>
> --
> 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/CAHwHwmVgJV3hj0PLn1_ntvjhWWGJRCYwNcprfQk-p%3DeZPMRU_A%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 
https://groups.google.com/d/msgid/django-developers/CAJxq848bcHhP4mF-6DNbPjQt%2BaO-%2BOGj%3D6S4tBhG5Z13UqQk0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: MySQL data loss possibility with concurrent ManyToManyField saves

[Cristiano Coelho]

What performance changes can you expect doing this change? It is probably 
that default on MySQL for a good reason.

-- 
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/8fe33fc0-5a55-479b-99b4-fbebc3bcf128%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: MySQL data loss possibility with concurrent ManyToManyField saves

[Curtis Maloney]

+1 for me, too...  this aligns with "safe/secure by default".

--
C

On 21/03/16 09:13, Aymeric Augustin wrote:

I agree with Karen.

--
Aymeric.


On 18 Mar 2016, at 22:15, Karen Tracey > wrote:

This is the 2nd major issue I can recall caused by MySQL default of
REPEATABLE READ transaction isolation level. I think Django should
simply switch itself to a default of using READ COMMITTED, consistent
with (all?) other supported database backends, and document how, if a
user really really wants to use REPEATABLE READ, they can do so (I
assume Django could allow that?), and what known problems when using
basic Django functions they may run into if they do so.

I fear our existing approach of documenting how certain functions
don't work by default on MySQL (e.g. get_or_create) is not really
helping the majority of our users. I believe switching instead to
making Django code itself work by default on MySQL would be a better
long-term solution for those who use MySQL with Django, and avoid
future cases like this one that has been discovered (years after we
knew get_or_create was broken by default transaction isolation level
on MySQL).

On Mon, Mar 14, 2016 at 11:15 AM, Tim Graham > wrote:

Could some MySQL users take a look at ticket #26347 [0] and
recommend how to proceed? I think it's probably not a new issue
but I'm a bit surprised it hasn't come up before if so.

[0] https://code.djangoproject.com/ticket/26347

--
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/286b0efb-673f-42d7-a1f3-5de76fc039c5%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/CACS9rae4U0e80-h%3DesTXFUi%3DLxWQ-XiMAp%3DAdkXcR0FnJVT2Cg%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
https://groups.google.com/d/msgid/django-developers/176B63AA-95D8-4D8B-B8EB-6A0AF95EEB9B%40polytechnique.org
.
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/56EF311B.701%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: MySQL data loss possibility with concurrent ManyToManyField saves

[Aymeric Augustin]

I agree with Karen.

-- 
Aymeric.

> On 18 Mar 2016, at 22:15, Karen Tracey  wrote:
> 
> This is the 2nd major issue I can recall caused by MySQL default of 
> REPEATABLE READ transaction isolation level. I think Django should simply 
> switch itself to a default of using READ COMMITTED, consistent with (all?) 
> other supported database backends, and document how, if a user really really 
> wants to use REPEATABLE READ, they can do so (I assume Django could allow 
> that?), and what known problems when using basic Django functions they may 
> run into if they do so.
> 
> I fear our existing approach of documenting how certain functions don't work 
> by default on MySQL (e.g. get_or_create) is not really helping the majority 
> of our users. I believe switching instead to making Django code itself work 
> by default on MySQL would be a better long-term solution for those who use 
> MySQL with Django, and avoid future cases like this one that has been 
> discovered (years after we knew get_or_create was broken by default 
> transaction isolation level on MySQL).
> 
> On Mon, Mar 14, 2016 at 11:15 AM, Tim Graham  > wrote:
> Could some MySQL users take a look at ticket #26347 [0] and recommend how to 
> proceed? I think it's probably not a new issue but I'm a bit surprised it 
> hasn't come up before if so.
> 
> [0] https://code.djangoproject.com/ticket/26347 
> 
> 
> -- 
> 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/286b0efb-673f-42d7-a1f3-5de76fc039c5%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/CACS9rae4U0e80-h%3DesTXFUi%3DLxWQ-XiMAp%3DAdkXcR0FnJVT2Cg%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 
https://groups.google.com/d/msgid/django-developers/176B63AA-95D8-4D8B-B8EB-6A0AF95EEB9B%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Help!!

[gilberto dos santos alves]

hi. this a list for django-development discussions. but anyway
for python tutorial [1] see

[1] https://docs.python.org/2/tutorial/

2016-03-20 14:31 GMT-03:00 Chitra Sivakumar :

> Hi ,
>
> I am new to open source and python, I am interested in doing open source
> contribution. It will be great !! if some mentor can help me getting
> started.
>
> regards
> chitra
>
> --
> 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/CAHwHwmVgJV3hj0PLn1_ntvjhWWGJRCYwNcprfQk-p%3DeZPMRU_A%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
gilberto dos santos alves
+55(11)9-8646-5049
sao paulo - sp - brasil

-- 
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/CAP9G-NK6151MFJP5e1EiF2gYCHdB%3DoZwkNLFxHvkOo1TosqQkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: relative path in {% extends "...base.html" %} like relative import

[Florian Apolloner]

On Sunday, March 20, 2016 at 5:57:41 PM UTC+1, Collin Anderson wrote:
>
> Hmm... I suppose the closest alternative we have would be to store the 
> base template name in a variable and pass it in from the view.
>

Either way, I fail to see how that feature would be really useful.

-- 
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/e4277a2f-80f4-499f-8428-e893f84d1227%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoC 2016]Proposal: Validity check at client and dynamic form framework

[Cristiano Coelho]

The client side validation is a very good idea, other frameworks such as 
ASP.NET MVC already has some basic client side validation tied to model 
fields (equivalent to django forms) and also provides a very easy way to 
add custom javascript validation and tie to the model/form.

For the second part about dynamic forms, it really looks complicated to 
implement, looks like a job for more than one person.

-- 
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/62a566fd-f30f-4238-872e-55c36441d44f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Help!!

[Chitra Sivakumar]

Hi ,

I am new to open source and python, I am interested in doing open source
contribution. It will be great !! if some mentor can help me getting
started.

regards
chitra

-- 
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/CAHwHwmVgJV3hj0PLn1_ntvjhWWGJRCYwNcprfQk-p%3DeZPMRU_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: relative path in {% extends "...base.html" %} like relative import

[Collin Anderson]

Hmm... I suppose the closest alternative we have would be to store the base
template name in a variable and pass it in from the view.

On Fri, Mar 18, 2016 at 12:42 PM, Vitaly Bogomolov 
wrote:

> Hi, All.
>
> For django.template.backends.django.DjangoTemplates (filesystem and
> app_directories) it can be very useful. This can be implemented?
>
> WBR, Vitaly.
>
> --
> 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/ccb20872-b91c-493b-b9f6-b4a28170cb99%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/CAFO84S4Q9qmqNGaZzoJEH-Jtzc2RwevjES9oPuQUV3W%2B0i824w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[GSoC 2016]Proposal: Validity check at client and dynamic form framework

[Lover Di]

Hi,

I have been working for preparing a proposal about a new feature for 
Django. I'm posting my draft proposal to Gist and want to know my idea is 
OK or not. So I can proceed with the right approach. Any suggestions or 
advice are welcome.

Abstract of my proposal:

   - Automatically generate some simple javascript code to check the 
   validity for forms
   - Many dynamic forms use similar logic, they can be abstracted into a 
   framework to help generated view code and javascript code, users only need 
   to fill out the logic of "how to change". Thus, the workload of write 
   dynamic form greatly reduced.


Proposal URL: https://gist.github.com/7sDream/46de98da073b9021c5d0

Regards,

7sDream

-- 
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/c9f6456d-176e-4764-a4a0-b1c3060453f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Override the default form field for a model field

[James Pic]

Yes, overriding the model field to change the definition of
formfield() works. It is indeed possible to define two model field
classes which have different formfield() methods, for example:

ManyToManyCheckboxField()
ForeignKeyRadioField()

Should Django provide such fields ?

formfield_callback is documented here:

https://docs.djangoproject.com/ja/1.9/ref/forms/models/#modelform-factory

It is one of the many ways there are to create a model form which
provides a radio widget for a foreign key for example.

However, the modelform then has to be passed around / inherited from
everywhere then.

Issue #26369 is about overriding the default widget that is used by a
formfield. The user story is like: I change the default widget used
for a model field and this change is applied everywhere.

Does this help to see the difference between just overriding in a
subclass, and overriding the default used by ModelForm ?

[0] https://code.djangoproject.com/ticket/26369

-- 
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/CALC3Kaf5%3D0qNNq%3DdXbJWVxYQOb42VjnwhJ5E5TWHJhLHBQBCww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Proposal: change to the way list_editable form data is submitted in the admin

[John C]

Hey,

For the past five years, I've been using Django to manage a database of 
online applications. I absolutely love it! Makes my job so much easier.

In general, any problems I run into, there's usually an easy workaround. 
But I wonder if that's even feasible in this case. Anyway, here's the 
problem: in managing submissions we make a lot of use of the list_editable 
attribute of ModelAdmin, particularly for status columns. It's extremely 
handy to be able to load up a list, filter it, and then make status changes 
to selected records all in one go.

However, there are times when these status columns are also changing on 
their own, due to what's happening on the front end. I have to be very 
careful to ensure that this doesn't happen in between when I load an admin 
list and when I click "Save." If so, then I may end up overwriting the 
newly changed data, back to what it was when the list was loaded in my 
browser. This is because all rows are always saved, based on the data in 
the form inputs from the list.

I propose that a copy of the list_editable values be sent along as a hidden 
form element (or, alternatively, that Javascript be used to detect values 
changed in response to user input). That way, in the admin form handler, 
only rows that have been intended to be changed would be updated to 
submitted values.

It adds some complexity, sure, but are there any disadvantages I haven't 
thought of? From my perspective, it would solve a rather frustrating 
problem.

Thanks,
John Cronan

-- 
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/03b8696e-a71f-4757-a95d-8312ce98321d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: FileField and ImageField

[Cristiano Coelho]

I agree with you, generate_filename should just call the field upload_to 
and then delegate the whole name generation to the storage.

There's another thing about file storage that is troubling me: 
https://github.com/django/django/blob/master/django/core/files/storage.py#L57

The docs state you are not suposed to override the save method and just 
implement _save, however, doing a complete random rename at the send pretty 
much forces you to always override save instead. That name replacement is 
probably to save the file name in a way you can easily create the URL, but 
again, that should be delegated to the storage.url method shouldn't it?

There's one more thing I noticed (gonna open a ticket about this one) is 
that the proxy class for FileField (FieldFile, what a name!) states in the 
docs that in order to call its save method you need a django File object 
rather than a simple file-like object, I can understand that's because the 
save method uses the .size property 
(https://github.com/django/django/blob/master/django/db/models/fields/files.py#L92)
 
to save the file size into a _size variable. It doesn't seem anywhere in 
the code the _size is being used as size is a property that gets the file 
size either from the storage class or the actual file. So removing that 
line, could also allow us to use normal files in the save method.

El miércoles, 16 de marzo de 2016, 23:41:58 (UTC-3), Josh Smeaton escribió:
>
> It seems like FileField should delegate some of these methods to an 
> underlying Storage backend, no? I don't know what the implications to 
> back-compat would be, but the idea seems like a sensible one to start with. 
> The storage backend API may need to grow some additional methods to 
> verify/validate paths and filenames or it might already have the correct 
> methods needed for FileField to work. Fields should do all of their 
> path/storage IO via their storage object though.
>
>
> On Thursday, 17 March 2016 12:16:00 UTC+11, Cristiano Coelho wrote:
>>
>> To add a bit more about this, it seems that FileField is really meant to 
>> be working with an OS file system, making it harder to use a custom Storage 
>> that sends data to somewhere like AWS S3 where basically everything is a 
>> file (there are no real folders, just key prefixes)
>>
>> These 3 functions inside FileField are the culprits:
>>
>> def get_directory_name(self):
>> return 
>> os.path.normpath(force_text(datetime.datetime.now().strftime(force_str(self.upload_to
>>
>> def get_filename(self, filename):
>> return 
>> os.path.normpath(self.storage.get_valid_name(os.path.basename(filename)))
>>
>> def generate_filename(self, instance, filename):
>> # If upload_to is a callable, make sure that the path it returns is
>> # passed through get_valid_name() of the underlying storage.
>> if callable(self.upload_to):
>> directory_name, filename = 
>> os.path.split(self.upload_to(instance, filename))
>> filename = self.storage.get_valid_name(filename)
>> return os.path.normpath(os.path.join(directory_name, filename))
>>
>> return os.path.join(self.get_directory_name(), 
>> self.get_filename(filename))
>>
>>
>>
>> They basically destroy any file name you give to it even with upload_to. 
>> This is not an issue on a storage that uses the underlying file system, but 
>> it might be quite an issue on different systems, in particular if file 
>> names are using slashes as prefixes.
>>
>> So what I did was to override it a bit:
>>
>> class S3FileField(FileField):
>>  
>> def generate_filename(self, instance, filename):
>> # If upload_to is a callable, make sure that the path it returns is
>> # passed through get_valid_name() of the underlying storage.
>> if callable(self.upload_to):
>> filename = self.upload_to(instance, filename)
>> filename = self.storage.get_valid_name(filename)
>> return filename
>>
>> return self.storage.get_valid_name(filename)
>>
>>
>> And all S3 issues gone! I wonder if this is the best way to do it. It 
>> would be great to have an additional keyword argument or something on the 
>> File (and image) fields to let the above functions know that they should 
>> not perform any OS operation on paths but seems like it would cause a lot 
>> of trouble.
>>
>

-- 
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/0d07079b-789f-413f-a578-674fc6febaa6%40googlegroups.com.
For more options, visit 

relative path in {% extends "...base.html" %} like relative import

[Vitaly Bogomolov]

Hi, All.

For django.template.backends.django.DjangoTemplates (filesystem and 
app_directories) it can be very useful. This can be implemented?

WBR, Vitaly.

-- 
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/ccb20872-b91c-493b-b9f6-b4a28170cb99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.