Re: [contrib][admin]: Grouping actions

[German Larrain]

Hi Stan.

I'm currently looking for "admin-related" features that seemed to be kind 
of accepted by the core developers.

What's the status of your proposal for grouping actions?

Best regards,
Germán Larraín

On Thursday, March 28, 2013 8:51:10 AM UTC-5, Stan wrote:
>
>
>
> On Thursday, March 28, 2013 1:50:36 PM UTC+1, Aymeric Augustin wrote:
>>
>>
>> On 28 mars 2013, at 12:21, Stan  wrote: 
>>
>> > Do you guys think it worth the effort to backport the functionality 
>> into admin ? 
>>
>>
>> Hi Stan, 
>>
>> I like this idea. 
>>
>> In terms of API, is there a particular reason why you chose to add an 
>> attribute to the actions themselves? I'd prefer to support a nested 
>> structure for ModelAdmin.actions, because it gives control on order of the 
>> groups and if feels more natural 
>
>
> Agreed. The first implementation was a nested tuple/list:
>
> ( 
>   ('group 1', ['actionA', 'actionB', ...]),
>   ('group 2', ['actionX', 'actionY', ...]),
> )
>  
> But it wasn't DRY enough because I had to maintain 2 structures of actions 
> (in the admin and in the front-end logic).
> So I add that attribute - which is harmless - and process the 
> ModelAdmin.actions in the front-end.
>
> Anyway,
>
> The nested structure is certainly better option (with a fallback on the 
> simple list we are used to.)
>
> ---
> Stanislas
>
>
>
>
> — there's less action at a distance. 
>>
>> -- 
>> Aymeric. 
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: make the source code of the django tutorial available ?

[German Larrain]

I know there are different opinions on this topic but if anyone is 
interested, I created a repo for the tutorial. The idea is to have branches 
and tags that match those of the documentation.

https://github.com/glarrain/django-tutorial-source-code

A nice advantage of that is to be able to compare how the resulting code of 
the official tutorial changes between releases. Others are:

   - Be able to check that the tutorial is correct (it's kind of difficult 
   to spot mistakes from the documentation, either rendered or rst), i.e. the 
   code works (in fact, I think I discovered a bug in the current master, 
   which I will file in trac ASAP).
   - Let the user compare at the end of the tutorial the code he/she typed 
   with the one in the repo.

Best regards,
Germán

On Wednesday, January 16, 2013 11:28:42 PM UTC-6, Russell Keith-Magee wrote:
>
>
>
> On Thu, Jan 17, 2013 at 1:17 PM, Daniel Greenfeld 
> 
> > wrote:
>
>>
>>
>> On Wednesday, January 16, 2013 4:43:14 PM UTC-8, Russell Keith-Magee 
>> wrote:
>>
>>> Hi Daniele,
>>>
>>> On Thu, Jan 17, 2013 at 7:07 AM, Daniele Procida 
>>> wrote:
>>>

  2) This is what version control is for. I'd much rather see someone do 
>>> the tutorial and use version control on their own repository, rather than 
>>> just pull down the latest version of a repo that contains all the code they 
>>> need.
>>>
>>> Following point 2, it might be worth suggesting that people use version 
>>> control during the tutorial. I'm not suggesting we turn the Django tutorial 
>>> into a parallel tutorial on git, but seeding the idea in people's heads has 
>>> the benefit of reinforcing best practice (you do version control everything 
>>> you do, right?), and makes it easier to work around the rollback problems 
>>> you describe; if they don't know what version control is, they might be 
>>> encouraged to go investigate, and as a result, another code-fairy gets 
>>> their wings :-)
>>>
>>
>> There are already third-party versions of the Django tutorial that also 
>> instruct on source control and TDD. These are great, and wonderful, but I 
>> feel they overwhelm beginner Django developers with too much. 
>>
>
> To be clear -- I'm not suggesting we try and make the Django tutorial a 
> parallel tutorial on source control. I'm just suggesting that we drop a 
> gentle hint at the start of the tutorial, to the effect of:
>
> "If you know how to use a source control system (like Git), you might want 
> to set up your tutorial directory as a repository. 
>
> If you don't know how to use a source control system, don't worry. You 
> don't need to know anything about source control to complete this tutorial. 
> However, source control systems are incredibly useful tools that are used 
> widely in software development, and you'd be well advised to learn how to 
> use them."
>
> and then, after completing relevant blocks of work:
>  
> "If you're using source control on this project, now would be a good time 
> to commit what you've done."
>
> The aim is to encourage best practice, or at least make users *aware* of 
> best practice, but leave the details up to them.
>
> Yours,
> Russ Magee %-)
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Kickstarter for Django Admin?

[German Larrain]

BTW, the URLs
http://blog-amirouche.dotcloud.com/notes/2013/admin-next-a-new-api.html
http://amirouche.github.io/blog/django-admin-next-a-new-api.html
lead to 404s.

The correct one is
http://www.hypermove.net/notes/2013/admin-next-a-new-api.html

On Saturday, March 30, 2013 5:49:27 PM UTC-5, Amirouche Boubekki wrote:
>
>
> 2013/3/30 Victor Hooi >
>
>> heya,
>>
>> Aha, yes - we need a roadmap, and somebody from the team to execute it 
>> *grins*.
>>
>> For the former - I believe there was already discussions on that sort of 
>> thing on this board?
>>
>> There's a wiki page with some notes as well:
>>
>> https://code.djangoproject.com/wiki/AdminNext
>>
>> I also had a look at some of the existing projects:
>>
>>- https://github.com/yawd/yawd-admin
>>- https://github.com/michaelhelmick/django-bootstrap-admin (Doesn't 
>>appear to be too active)
>>- https://github.com/riccardo-forina/django-admin-bootstrapped
>>- https://github.com/aobo711/bootstrap-django-admin
>>- 
>> https://github.com/gkuhn1/django-admin-templates-twitter-bootstrap(Doesn't 
>> appear to be too active)
>>- https://github.com/divio/djangocms-admin-style
>>
>> And there's obviously Grapelli.
>>
>> A lot of these are obviously just reskins, while others offer a bit more.
>>
>> From the existing projects, we can draw two clear requirements that 
>> people want:
>>
>>- Changing the look and feel - I'm not sure what Django core's 
>>feelings on it, but there seems to be a feeling from the community that 
>> the 
>>look of the current Django Admin is somewhat dated? Also, any new admin 
>>should probably be responsive, and work on mobile or non-desktop devices, 
>>if that's possible. 
>>
>>
> This question leads to another should Django develop its own css framework 
> and re-use existing one, if Django use an existing one, Django must make it 
> easy to work with the preprocessor. While I liked much bootstrap, 
> foundation's mobile first approach of Foundation is appealing even if more 
> verbose.
>  
>
>>
>>- More customisations -  a lot of people want to create dashboards 
>>around the admin, add new sections/tabs, or move things around - the 
>>current Admin doesn't have much scope for that, or it's not easily 
>>accessible. 
>>
>> Those are all things that are doable right now. I though it was about 
> something more «disruptive» that's why I called the page AdminNext to 
> follow the naming of next html version... whatever the naming, the goal 
> should be the same aka. not only a cbv-Admin which should only adress the 
> customisability (and readability) side but add features. This lead me to 
> the group/permission-centric admin which creates menu based on permissions, 
> but I did not implement it. I've documented a sketch API [1], but I'm not 
> very happy with it, I'm now thinking about something in the spirit of 
> lettuce to create an admin.
>
> I stopped working on the composite admin because a) the composite thing is 
> too much b) I wasn't confortable with the code handling inlines in current 
> admin so I started thinking about fixing it but got stuck (!).
>
> Also there is this conversation that is somehow related: 
> https://groups.google.com/forum/#!msg/django-developers/wI18E6BZImQ/TS2wSvUCkaAJ
>
> Maybe Django should gather money somehow and tell a company to do the job 
> instead of relying on the community ?
>
> HTH,
>
> Amirouche
>
> [1] http://amirouche.github.com/blog/django-admin-next-a-new-api.html
>
>  
>
>> For the latter, not sure I can help you there...lol. I thought Idan Gazit 
>> was working on something before though? Or are there other designers on the 
>> Core team? 
>>
>> Cheers,
>> Victor
>>
>> On Sunday, 24 March 2013 22:14:58 UTC+11, Russell Keith-Magee wrote:
>>
>>>
>>> On Sun, Mar 24, 2013 at 6:20 PM, Victor Hooi  wrote:
>>>
 Hi,

 I read recently about Andrew Goodwin's successful kickstarter project 
 for better Django schema migrations:

 http://www.kickstarter.com/**projects/andrewgodwin/schema-**
 migrations-for-django

 Kudos to him for awesome work on South so far a swell =).

 There doesn't seem to be much movement on the Admin front - 
 https://groups.google.com/d/**msg/django-developers/**
 Vozu6U3gz84/vvbTqrWitxIJ

 I'm wondering - is there any impetus for a similar kickstarter for the 
 Django admin?

 I for one would be willing to put my money where my mouth is and back 
 it - and I'm sure other people/companies who use Django in their own 
 projects would as well.

>>>
>>> Good to hear :-)
>>>
>>> There's one significant difference here. Andrew's project was to deliver 
>>> South-like functionality to trunk. South is a known quantity, and there 
>>> have been discussions and threads about ex

Re: Order of INSTALLED_APPS

[German Larrain]

Hi guys

A related question: What about repeated entries of apps in INSTALLED_APPS? 
I remember seeing this once and, if I recall correctly, no errors were 
raised. I guess ImproperlyConfigured would be a suitable exception.

Germán

On Tuesday, August 13, 2013 5:09:45 AM UTC-5, Stefano Crosta wrote:
>
> Aymeric, Ramiro, Florian,
>
> thanks a lot for your answers!
>
> Indeed there is some (slightly hidden :D ) documentation! 
> And it has improved since 1.5, I now see! - I remembered reading something 
> before, but I couldn't find them anymore when I wrote yesterday's message.
>
> My proposal would then be to simply add another box to the 
> https://docs.djangoproject.com/en/dev/ref/settings/#installed-apps to say 
> "order matters" once more and link the other two pages for translations and 
> templates.
> *if you think this would* help I could do it as well as a ticket. To save 
> everybody's time no answer will mean it's not worth it!
>
> (PS. Also please fully disregard my momentary lapse of reason concerning 
> `sets` in the settings - I don't know what got into me)
>
> thanks&best,
> Stefano
>
>
> On Monday, August 12, 2013 8:29:49 PM UTC+2, Florian Apolloner wrote:
>>
>> On Monday, August 12, 2013 3:41:15 PM UTC+2, Ramiro Morales wrote:
>>>
>>> For translations, we have such documentation already: 
>>>
>>>
>>> https://docs.djangoproject.com/en/1.5/topics/i18n/translation/#how-django-discovers-translations
>>>  
>>>
>>
>> For templates too: 
>> https://docs.djangoproject.com/en/dev/ref/templates/api/#django.template.loaders.app_directories.Loader--
>>  but I agree it's somewhat hidden ;) 
>>
>> Florian
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Backwards compatibility and field validation

[German Larrain]

FWIW I was very surprised when I realized this problem. I couldn't understand 
why a model object with an email field (without `blank=True`) could be saved 
with an empty string as email address.

The way I dealt with this was creating a mixin (ValidateModelMixin) and adding 
it as left-most superclass in all the models where I needed 'full_clean' to be 
called before 'save'.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2cb7893e-28e6-4a65-a882-671bcf26c50a%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: When to use single quotes and double quotes

[German Larrain]

> Use double quotes for strings meant for human consumption, use single 
> quotes for everything else. 
>
> Text, trans strings, model verbose_names: double quotes 
> Dict keys, HTML tags, flags, and similar: single quotes 
>
> Use triple quotes for long blocks of text, ideally only necessary for 
> human-readable strings. 
>
>
I had somewhat the same idea but your rule-of-thumb makes it way easier to 
remember! Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4d190dc3-5a5d-4dec-8bff-48a157b8725e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Should AdminSite be able to handle different namespace?

[German Larrain]

Hi guys

I must say I hit this issue a few months ago (I have more than one admin 
app living side by side). It was confusing, when reversing a URL name, 
whether to change 'admin' in a string like this `'admin:%s_%s_change'`, or 
use `current_app=self.admin_site.name`.

Since I don't like hardcoded strings and I (or someone using my 
code) would probably get confused over this at a later point, I created a 
utility function that perhaps may be useful for someone else and/or to 
clarify the problem:

def get_admin_view_url_name(model, view, admin_site=None):
admin_site = admin_site or 'admin'

# TODO: replace `module_name` with `model_name` when using Django 1.6
return '%s:%s_%s_%s' % (
admin_site,
model._meta.app_label,
model._meta.module_name,
view)

Just my 2 cents.

Germán

On Wednesday, November 13, 2013 9:06:50 AM UTC-3, Florian Apolloner wrote:
>
> Hi Russ,
>
> On Wednesday, November 13, 2013 2:16:13 AM UTC+1, Russell Keith-Magee 
> wrote:
>>
>> The use case was simple -- deploy two instances of admin in a single 
>> project. For example, you might have a truly 'access-all-areas' admin, and 
>> a cut down/modified admin for trusted editors that has specially customised 
>> workflows, etc. Admin has been specifically designed to allow this, and 
>> it's a documented feature [1].
>>
>
> This is something which can be done currently by supplying the name 
> argument to the AdminSite [1] (this changes the instance namespace name for 
> the urlconf). But we also have a lesser known (and not working) feature 
> where you can also modify the app_name itself [2] -- which is causing 
> problems here (application namespace vs instance namespace). I am not sure 
> what app_name provides aside from more complexity :)
>
> Cheers,
> Florian
>
> [1] 
> https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.AdminSite
>  
> [2] 
> https://github.com/django/django/blob/master/django/contrib/admin/sites.py#L55
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5aa1d9c9-363a-4299-98ff-0a0923e8200e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Should AdminSite be able to handle different namespace?

[German Larrain]

Hi Florian

I used to do that (pass `current_app='other_admin'` to reverse) and it 
worked fine until I hit a bump road (sorry, can't remember which) where I 
couldn't reverse to the admin site that I wanted by using `current_app` (it 
reversed to the "main" one if the URL name existed else raised a 
NoReverseMatch). And reading the docs again:

AdminSite instances take a single argument to their constructor, their 
> name, which can be anything you like. This argument becomes the prefix to 
> the URL names for the purposes of reversing them. This is only necessary if 
> you are using more than one AdminSite.

https://docs.djangoproject.com/en/1.6/ref/contrib/admin/#multiple-admin-sites-in-the-same-urlconf

So the name of the "other admin" becomes the prefix to the URL names for 
the purpose of reversing them.

Now I'm more confused.
 

On Thursday, November 14, 2013 7:45:39 AM UTC-3, Florian Apolloner wrote:
>
> Hi Germán,
>
> in your case you should be using current_app; then using 
> reverse('admin:bla') will tell the urlresolver to reverse an admin url bla 
> for an AdminSite with name == current_app -- this will also work in 
> templates; which is good since you really don't want to change string 
> there… When you need to refer to the "other" admin just pass 
> current_app='other_admin' to reverse.
>
> Chers,
> Florian
>
> On Thursday, November 14, 2013 1:55:13 AM UTC+1, German Larrain wrote:
>>
>> Hi guys
>>
>> I must say I hit this issue a few months ago (I have more than one admin 
>> app living side by side). It was confusing, when reversing a URL name, 
>> whether to change 'admin' in a string like this `'admin:%s_%s_change'`, or 
>> use `current_app=self.admin_site.name`.
>>
>> Since I don't like hardcoded strings and I (or someone using my 
>> code) would probably get confused over this at a later point, I created a 
>> utility function that perhaps may be useful for someone else and/or to 
>> clarify the problem:
>>
>> def get_admin_view_url_name(model, view, admin_site=None):
>> admin_site = admin_site or 'admin'
>>
>> # TODO: replace `module_name` with `model_name` when using Django 1.6
>> return '%s:%s_%s_%s' % (
>> admin_site,
>> model._meta.app_label,
>> model._meta.module_name,
>> view)
>>
>> Just my 2 cents.
>>
>> Germán
>>
>> On Wednesday, November 13, 2013 9:06:50 AM UTC-3, Florian Apolloner wrote:
>>>
>>> Hi Russ,
>>>
>>> On Wednesday, November 13, 2013 2:16:13 AM UTC+1, Russell Keith-Magee 
>>> wrote:
>>>>
>>>> The use case was simple -- deploy two instances of admin in a single 
>>>> project. For example, you might have a truly 'access-all-areas' admin, and 
>>>> a cut down/modified admin for trusted editors that has specially 
>>>> customised 
>>>> workflows, etc. Admin has been specifically designed to allow this, and 
>>>> it's a documented feature [1].
>>>>
>>>
>>> This is something which can be done currently by supplying the name 
>>> argument to the AdminSite [1] (this changes the instance namespace name for 
>>> the urlconf). But we also have a lesser known (and not working) feature 
>>> where you can also modify the app_name itself [2] -- which is causing 
>>> problems here (application namespace vs instance namespace). I am not sure 
>>> what app_name provides aside from more complexity :)
>>>
>>> Cheers,
>>> Florian
>>>
>>> [1] 
>>> https://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.AdminSite
>>>  
>>> [2] 
>>> https://github.com/django/django/blob/master/django/contrib/admin/sites.py#L55
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0652b37c-75e5-47bd-bd9a-622a9cea86c3%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Should AdminSite be able to handle different namespace?

[German Larrain]

>
> On Thursday, November 14, 2013 12:55:32 PM UTC-3, Amirouche Boubekki wrote:
>>
>>
>> 2013/11/14 Florian Apolloner 
>>
>>> We might have to fix the docs there :)
>>>
>>
>> It's was fixed somewhat [1]. ...
>>
>  
>
 
I think Florian refers to other part, which is indeed wrong. I just 
submitted a ticket  with patch 
for that.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4d5401e6-0870-4a2c-a29a-9890ab6e5066%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Should AdminSite be able to handle different namespace?

[German Larrain]

I had the same confusion that you seem to have. There is a difference 
between application namespace and instance namespace. Because usually you 
only have one instance of each of the installed apps, you don't need to 
pass `current_app=mycoolappname_instanceX`.

In the case of multiple admin instances, the application namespace (which 
is the argument `app_name` to the constructor of AdminSite, and the 
original topic of this post) will be 'admin' for all of them, thus the 
necessity to differentiate to which instance you wish to reverse a URL name 
by passing 'current_app' to the reverse function. Nonetheless, if none is 
given, the reverse will still work and will default to the first urlconf 
that matches the corresponding application namespace.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3fa60d60-d9db-40c1-bef9-54b98fbadab2%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Self-referenced template recursion handling

[German Larrain]

On Friday, December 6, 2013 11:36:00 AM UTC-3, unai wrote:
>
> Lot of app/CMS creators create base templates for their apps. Currently, 
> if one 
> of those templates needs some kind of change, the user needs to copy the 
> template all over again, making it difficult to update their templates 
> when 
> they update their apps (they would need to copy the new template and then 
> make 
> their customizations again). 
>
> Skipping the current template loader means that they would be able to 
> create 
> their own template (with the same path as the app template), extend it to 
> itself and only change the blocks that need to be changed.
>

 I would love this feature because I've faced the mentioned problems.

Germán

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/03cfd51f-4abe-4f6c-94d5-b06ec3e4eff9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Renaming apps.has_app

[German Larrain]

+1 for is_installed

Aymeric, thanks for your work

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/04aa7e6b-75d0-45dd-89cf-78e8ff83b3c3%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Feature request: serve_file() view in static app

[German Larrain]

PyPI packages 'static' and 'dj-static' might help you.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55985ad8-990c-4341-b876-167eb7a1a3fa%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.