Implement form.as_table, as_ul, as_p using templates

[Gert Steyn]

Hi All

Is anybody against using the new renderers (used to render widgets) to also 
render the form?

I suggest something like:

class BaseForm(object):
template_prefix = ''
template_name = 'django/forms/form_as_table.html'

def render(self, template_name=None):
template_name = template_name or self.get_template_name()
context = self.get_context()
self._render(template_name, context, self.renderer)

def get_template_name(self):
return self.template_prefix + self.template_name

def as_table(self):
return self.render(template_name='django/forms/form_as_table.html')

def as_ul(self):
return self.render(template_name='django/forms/form_as_ul.html')

def as_p(self):
return self.render(template_name='django/forms/form_as_p.html')


Exact same argument as with widgets, currently the form HTML is generated 
in Python code where it is hard to customise, HTML templates belong in 
well... templates!

Thanks
Gert

The template_prefix gives you the ability to easily switch between 
different form layouts (think Bootstrap, Foundation etc). Similar idea as 
the as_table, as_ul, as_p functions, just not hard coded. As Florian 
suggested in my previous post, it would be nice to be able to set the 
prefix from the template side as well {% form my_form prefix='bootstrap' %}.




-- 
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/5c52974d-48f2-4354-95e5-ced594b78f0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code 2017

[HITESH V. BHAGCHANDANI]

My college blocks ports for IRC and am unable to communicate freely with 
the django community. By the way, I have joined only a few days ago and 
would like to know where I can post my queries regarding details( which 
function to use, what file to edit and so on) about any patch that I'd be 
writing for a ticket. Is this mailing list the right place? 

On Saturday, January 21, 2017 at 2:27:33 AM UTC+5:30, Tim Graham wrote:
>
> I've submitted our organization application for this year.
>
> Anyone interested in mentoring, please indicate your interest 
> https://code.djangoproject.com/wiki/SummerOfCode2017. Any experienced 
> contributors are welcome to mentor. We also need project ideas on that 
> page. I've copied the ideas from past years, but they may not be the best. 
> If you have an idea in mind, feel free to start a new thread on this 
> mailing list to see if others think it's suitable.
>
> Any students interested in participating, the time to starting 
> contributing is now! The chances of developing a successful proposal 
> without any past contributions to Django is very low.
>
> If you have a question, let me know.
>

-- 
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/af1c446b-d543-4a9a-8bdf-33f3da1b60ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code 2017

[Tim Graham]

There are web clients for IRC such as irccloud.com that you can use to 
avoid port restrictions. This mailing list isn't the best place for basic 
contributing questions.

The #django-dev IRC channel or the mentorship mailing list could be 
suitable for new contributor questions.
https://groups.google.com/group/django-core-mentorship

If the question involves design decisions, commenting on the ticket you 
intend to work on might also be appropriate.

On Friday, February 3, 2017 at 7:16:48 AM UTC-5, HITESH V. BHAGCHANDANI 
wrote:
>
> My college blocks ports for IRC and am unable to communicate freely with 
> the django community. By the way, I have joined only a few days ago and 
> would like to know where I can post my queries regarding details( which 
> function to use, what file to edit and so on) about any patch that I'd be 
> writing for a ticket. Is this mailing list the right place? 
>
> On Saturday, January 21, 2017 at 2:27:33 AM UTC+5:30, Tim Graham wrote:
>>
>> I've submitted our organization application for this year.
>>
>> Anyone interested in mentoring, please indicate your interest 
>> https://code.djangoproject.com/wiki/SummerOfCode2017. Any experienced 
>> contributors are welcome to mentor. We also need project ideas on that 
>> page. I've copied the ideas from past years, but they may not be the best. 
>> If you have an idea in mind, feel free to start a new thread on this 
>> mailing list to see if others think it's suitable.
>>
>> Any students interested in participating, the time to starting 
>> contributing is now! The chances of developing a successful proposal 
>> without any past contributions to Django is very low.
>>
>> If you have a question, let me know.
>>
>

-- 
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/80139f20-6d58-4008-9a0a-1fb06711c222%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Implement form.as_table, as_ul, as_p using templates

[Tim Graham]

There's an old accepted ticket for it: 
https://code.djangoproject.com/ticket/16922. Reviewing the past discussion 
may help you refine your proposal.

On Friday, February 3, 2017 at 6:01:11 AM UTC-5, Gert Steyn wrote:
>
> Hi All
>
> Is anybody against using the new renderers (used to render widgets) to 
> also render the form?
>
> I suggest something like:
>
> class BaseForm(object):
> template_prefix = ''
> template_name = 'django/forms/form_as_table.html'
>
> def render(self, template_name=None):
> template_name = template_name or self.get_template_name()
> context = self.get_context()
> self._render(template_name, context, self.renderer)
> 
> def get_template_name(self):
> return self.template_prefix + self.template_name
>
> def as_table(self):
> return self.render(template_name='django/forms/form_as_table.html'
> )
>
> def as_ul(self):
> return self.render(template_name='django/forms/form_as_ul.html')
>
> def as_p(self):
> return self.render(template_name='django/forms/form_as_p.html')
>
>
> Exact same argument as with widgets, currently the form HTML is generated 
> in Python code where it is hard to customise, HTML templates belong in 
> well... templates!
>
> Thanks
> Gert
>
> The template_prefix gives you the ability to easily switch between 
> different form layouts (think Bootstrap, Foundation etc). Similar idea as 
> the as_table, as_ul, as_p functions, just not hard coded. As Florian 
> suggested in my previous post, it would be nice to be able to set the 
> prefix from the template side as well {% form my_form prefix='bootstrap' %}.
>
>
>
>
>

-- 
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/c4c33d4a-b5ec-49d7-af96-4f81cce1c5dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Implement form.as_table, as_ul, as_p using templates

[Gert Steyn]

Hi Tim

The implementation can be extremely simple as most of the heavy lifting has 
already been done for widget templates. The only new parts are:

   1. BaseForm.get_context
   2. The templates to implement as_table, as_ul and as_p
   3. A little bit of glue (render etc, pretty much the same as the 
   functions on Widget)
   4. {% form %} should just pass optional parameters (template_name, 
   prefix) to BaseForm.render
   
Before I work on refining the details, do you like the concept?

-- 
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/77af3417-d57b-43e2-bccb-3eb456e8b921%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Added signals that runs when adding an object to a Many-To-One relation

[Oskar Persson]

Hi everyone.

I've created a pull request (8018) 
 that adds the signals pre_add 
and post_add that are triggered when adding an object to a Many-To-One 
relation. The reason for this PR is to provide a simple (is there any 
other?) way to run custom code when ever adding an object to a Many-To-One 
relation. There already exists a signal for Many-To-Many 
 fields so 
why not for Many-To-One?

What are your thoughts on this?



Thanks

Oskar Persson

-- 
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/249d697b-f030-4112-a192-2c8510461f5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Added signals that runs when adding an object to a Many-To-One relation

[Paul Egges]

I thought a Many-To-One would not require an intermediate table, so it
would be caught by pre-save and post-save on the object containing the
Foreign Key. Is that not true?


Paul

On Fri, Feb 3, 2017 at 8:28 AM, Oskar Persson 
wrote:

> Hi everyone.
>
> I've created a pull request (8018)
>  that adds the signals
> pre_add and post_add that are triggered when adding an object to a
> Many-To-One relation. The reason for this PR is to provide a simple (is
> there any other?) way to run custom code when ever adding an object to a
> Many-To-One relation. There already exists a signal for Many-To-Many
>  fields
> so why not for Many-To-One?
>
> What are your thoughts on this?
>
>
>
> Thanks
>
> Oskar Persson
>
> --
> 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/249d697b-f030-4112-a192-
> 2c8510461f5b%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/CAD4jHOKKU55wSmsA9YYySAPJSRj8LCgXWuThfzKNtLx2CRRkPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Added signals that runs when adding an object to a Many-To-One relation

[Oskar Persson]

No, the save method isn't called unless you specify bulk=False 


Den fredag 3 februari 2017 kl. 17:53:04 UTC+1 skrev mtnpaul:
>
> I thought a Many-To-One would not require an intermediate table, so it 
> would be caught by pre-save and post-save on the object containing the 
> Foreign Key. Is that not true?
>
>
> Paul
>
> On Fri, Feb 3, 2017 at 8:28 AM, Oskar Persson  > wrote:
>
>> Hi everyone.
>>
>> I've created a pull request (8018) 
>>  that adds the signals 
>> pre_add and post_add that are triggered when adding an object to a 
>> Many-To-One relation. The reason for this PR is to provide a simple (is 
>> there any other?) way to run custom code when ever adding an object to a 
>> Many-To-One relation. There already exists a signal for Many-To-Many 
>>  fields 
>> so why not for Many-To-One?
>>
>> What are your thoughts on this?
>>
>>
>>
>> Thanks
>>
>> Oskar Persson
>>
>> -- 
>> 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/249d697b-f030-4112-a192-2c8510461f5b%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/e6e9a557-44f0-4489-bc11-baae40e35930%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Added signals that runs when adding an object to a Many-To-One relation

[Paul Egges]

Good to know.

Thanks,

Paul


On Fri, Feb 3, 2017 at 10:03 AM, Oskar Persson 
wrote:

> No, the save method isn't called unless you specify bulk=False
> 
>
> Den fredag 3 februari 2017 kl. 17:53:04 UTC+1 skrev mtnpaul:
>>
>> I thought a Many-To-One would not require an intermediate table, so it
>> would be caught by pre-save and post-save on the object containing the
>> Foreign Key. Is that not true?
>>
>>
>> Paul
>>
>> On Fri, Feb 3, 2017 at 8:28 AM, Oskar Persson 
>> wrote:
>>
>>> Hi everyone.
>>>
>>> I've created a pull request (8018)
>>>  that adds the signals
>>> pre_add and post_add that are triggered when adding an object to a
>>> Many-To-One relation. The reason for this PR is to provide a simple (is
>>> there any other?) way to run custom code when ever adding an object to a
>>> Many-To-One relation. There already exists a signal for Many-To-Many
>>> 
>>> fields so why not for Many-To-One?
>>>
>>> What are your thoughts on this?
>>>
>>>
>>>
>>> Thanks
>>>
>>> Oskar Persson
>>>
>>> --
>>> 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/ms
>>> gid/django-developers/249d697b-f030-4112-a192-2c8510461f5b%
>>> 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/e6e9a557-44f0-4489-bc11-
> baae40e35930%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/CAD4jHO%2Bd8ynm3zG23m0FBgE-mScgOxZfv%2BzhNaiyajMbAQp7Pw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Added signals that runs when adding an object to a Many-To-One relation

[Tim Graham]

#21461 proposes to add signals for QuerySet.update(). Would this solve your 
use case?

https://code.djangoproject.com/ticket/21461

On Friday, February 3, 2017 at 12:14:23 PM UTC-5, mtnpaul wrote:
>
> Good to know. 
>
> Thanks,
>
> Paul
>
>
> On Fri, Feb 3, 2017 at 10:03 AM, Oskar Persson  > wrote:
>
>> No, the save method isn't called unless you specify bulk=False 
>> 
>>
>> Den fredag 3 februari 2017 kl. 17:53:04 UTC+1 skrev mtnpaul:
>>>
>>> I thought a Many-To-One would not require an intermediate table, so it 
>>> would be caught by pre-save and post-save on the object containing the 
>>> Foreign Key. Is that not true?
>>>
>>>
>>> Paul
>>>
>>> On Fri, Feb 3, 2017 at 8:28 AM, Oskar Persson  
>>> wrote:
>>>
 Hi everyone.

 I've created a pull request (8018) 
  that adds the signals 
 pre_add and post_add that are triggered when adding an object to a 
 Many-To-One relation. The reason for this PR is to provide a simple (is 
 there any other?) way to run custom code when ever adding an object to a 
 Many-To-One relation. There already exists a signal for Many-To-Many 
  
 fields so why not for Many-To-One?

 What are your thoughts on this?



 Thanks

 Oskar Persson

 -- 
 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/249d697b-f030-4112-a192-2c8510461f5b%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-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/e6e9a557-44f0-4489-bc11-baae40e35930%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/0dd2fd46-fb1d-4e89-ab3f-a15b329012fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Added signals that runs when adding an object to a Many-To-One relation

[Oskar Persson]

It would. Though that seems like its trying to solve a bigger issue since 
then you probably *need* the updated objects, which I'm not including

Den fredag 3 februari 2017 kl. 18:21:55 UTC+1 skrev Tim Graham:
>
> #21461 proposes to add signals for QuerySet.update(). Would this solve 
> your use case?
>
> https://code.djangoproject.com/ticket/21461
>
> On Friday, February 3, 2017 at 12:14:23 PM UTC-5, mtnpaul wrote:
>>
>> Good to know. 
>>
>> Thanks,
>>
>> Paul
>>
>>
>> On Fri, Feb 3, 2017 at 10:03 AM, Oskar Persson  
>> wrote:
>>
>>> No, the save method isn't called unless you specify bulk=False 
>>> 
>>>
>>> Den fredag 3 februari 2017 kl. 17:53:04 UTC+1 skrev mtnpaul:

 I thought a Many-To-One would not require an intermediate table, so it 
 would be caught by pre-save and post-save on the object containing the 
 Foreign Key. Is that not true?


 Paul

 On Fri, Feb 3, 2017 at 8:28 AM, Oskar Persson  
 wrote:

> Hi everyone.
>
> I've created a pull request (8018) 
>  that adds the signals 
> pre_add and post_add that are triggered when adding an object to a 
> Many-To-One relation. The reason for this PR is to provide a simple (is 
> there any other?) way to run custom code when ever adding an object to a 
> Many-To-One relation. There already exists a signal for Many-To-Many 
>  
> fields so why not for Many-To-One?
>
> What are your thoughts on this?
>
>
>
> Thanks
>
> Oskar Persson
>
> -- 
> 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/249d697b-f030-4112-a192-2c8510461f5b%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-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/e6e9a557-44f0-4489-bc11-baae40e35930%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/b06b626f-0e84-46b6-a21a-e45067762d24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Implement form.as_table, as_ul, as_p using templates

[Josh Smeaton]

I like the concept, though I haven't looked into the 4 points you laid out. 
I like the concept of the prefix you mentioned in the widget thread also - 
I'd love to see template packs as third party libraries that easily slot in 
(per form I think is crucial).

I'm unsure of the proposed properties being template_name and prefix. I'd 
think something like this would be more appropriate:

template_module = 'django/forms/'

And then each of the render methods would be:

def as_table(self):
return 
self.render(template_name='{}form_as_table.html'.format(self.template_module))

Is it necessary to define both prefix and name?

On Saturday, 4 February 2017 00:41:07 UTC+11, Gert Steyn wrote:
>
> Hi Tim
>
> The implementation can be extremely simple as most of the heavy lifting 
> has already been done for widget templates. The only new parts are:
>
>1. BaseForm.get_context
>2. The templates to implement as_table, as_ul and as_p
>3. A little bit of glue (render etc, pretty much the same as the 
>functions on Widget)
>4. {% form %} should just pass optional parameters (template_name, 
>prefix) to BaseForm.render
>
> Before I work on refining the details, do you like the concept?
>
>

-- 
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/47741a4e-306e-4430-aeb9-489a86feec32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.