Re: Fellow Reports - October 2022

[Mariusz Felisiak]

Week ending October 30, 2022 

*Triaged: *
   https://code.djangoproject.com/ticket/34112 - Add async interface to 
Model (accepted) 
   https://code.djangoproject.com/ticket/34113 - max() arg is an empty 
sequence (duplicate) 
   https://code.djangoproject.com/ticket/34114 - loaddata doesn't honor 
auto_now_add=True when these values are missing. (duplicate) 
   https://code.djangoproject.com/ticket/34115 - Document RUN_MAIN 
environment variable (wontfix) 
   https://code.djangoproject.com/ticket/34116 - custom validation error in 
password_validators (wontfix) 
   https://code.djangoproject.com/ticket/33173 - Python 3.11 compatibility 
(accepted) 
   https://code.djangoproject.com/ticket/34118 - Python 3.12 compatibility 
(someday/maybe) 
   https://code.djangoproject.com/ticket/33701 - Highlight error location 
in the technical 500 debug page on Python 3.11+. (accepted) 
   https://code.djangoproject.com/ticket/33752 - Display exception groups 
on the technical 500 debug page on Python 3.11+. (accepted) 
   https://code.djangoproject.com/ticket/33747 - Display exception notes on 
the technical 500 debug page on Python 3.11+. (accepted) 
   https://code.djangoproject.com/ticket/34110 - Add InMemoryStorage 
(accepted) 
   https://code.djangoproject.com/ticket/34121 - Multi Databases 
documenation example doesn't work (invalid) 
   https://code.djangoproject.com/ticket/34109 - Uvicorn can be run without 
installing gunicorn (accepted) 
   https://code.djangoproject.com/ticket/34123 - Ambiguous aliases in 
ordering on combined queries with select_related(). (accepted) 
   https://code.djangoproject.com/ticket/34125 - Limiting QuerySet crashes 
on union() with a single non-empty query (accepted) 
   https://code.djangoproject.com/ticket/34124 - Developer experience on {% 
with %} template tag can be improved. (wontfix) 
   https://code.djangoproject.com/ticket/34127 - after package django 
project with pyinstall, with manage can't execute other commands defined in 
other python packages (invalid) 

*Reviewed/committed: *
   https://github.com/django/django/pull/16217 - Fixed #34111 -- Made test 
runner with --debug-sql format SQL queries. 
   https://github.com/django/django/pull/16220 - Improved "rebase" example 
for upstream changes in working with Git docs. 
   https://github.com/django/django/pull/16224 - Fixed flaky 
test_ForeignKey_using_to_field test. 
   https://github.com/django/django/pull/15863 - Fixed #34098 -- Fixed loss 
of precision for Decimal values in floatformat filter. 
   https://github.com/django/django/pull/16056 - Fixed #29027 -- Fixed 
file_move_safe() crash when moving files with SELinux. 
   https://github.com/django/django/pull/16187 - Fixed #19215 -- Fixed 
rendering ClearableFileInput when editing with invalid files. 
   https://github.com/django/django/pull/16222 - Completed test coverage 
for contrib.auth.forms. 
   https://github.com/django/django/pull/16139 - Fixed #34066 -- Fixed link 
to password reset view in UserChangeForm.password's help text when using 
to_field. 
   https://github.com/django/django/pull/16232 - Fixed #34125 -- Fixed 
sliced QuerySet.union() crash on a single non-empty queryset. 
   https://github.com/django/django/pull/16238 - Corrected 
test_update_or_create_with_model_property_defaults test. 
   https://github.com/django/django/pull/16234 - Removed obsolete doc 
reference to asyncio.iscoroutinefunction. 

*Authored: *
   https://github.com/django/django/pull/16223 - Refs #34070 -- Fixed date 
format in Now() on SQLite. 
   https://github.com/django/django/pull/16225 - Refs #33173 -- Fixed 
destroying test databases when running tests in parallel using spawn on 
Windows. 
   https://github.com/django/django/pull/16226 - Fixed 
DatabaseFeatures.supports_select_(intersection/difference) on MariaDB and 
MySQL 8.0.31+. 
   https://github.com/django/django/pull/16228 - Refs #33173 -- Added 
Python 3.11 to classifiers and tox.ini. 
   https://github.com/django/django/pull/16230 - Refs #33173 -- Doc'd 
Python 3.11 compatibility in Django 4.1.x. 
   https://github.com/django/django/pull/16231 - Refs #19215 -- Fixed 
admin_widgets tests if Pillow isn't installed.

Best,
Mariusz

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/919feb1b-824a-4195-8a3a-127e0f342dden%40googlegroups.com.

How reload django settings on run RestService

[Lakhvinder Singh]

i try it 

https://github.com/sunscrapers/djoser/blob/master/djoser/conf.py 

 user->settings.py use for settings load on global

from copy import deepcopy

from django.core.exceptions import ImproperlyConfigured
from django.conf import settings


default_settings = {
'SEND_ACTIVATION_EMAIL': False,
'SEND_CONFIRMATION_EMAIL': False,
'SET_PASSWORD_RETYPE': False,
'SET_USERNAME_RETYPE': False,
'PASSWORD_RESET_CONFIRM_RETYPE': False,
'PASSWORD_RESET_SHOW_EMAIL_NOT_FOUND': False,
'ROOT_VIEW_URLS_MAPPING': {},
'PASSWORD_VALIDATORS': [],
'SERIALIZERS': {
'activation': 'user.serializers.ActivationSerializer',
'login': 'user.serializers.LoginSerializer',

},
'LOGOUT_ON_PASSWORD_CHANGE': False,
}


def get(key):
user_settings = merge_settings_dicts(
deepcopy(default_settings), getattr(settings, 'USER_APP', {}))
try:
return user_settings[key]
except KeyError:
raise ImproperlyConfigured('Missing settings: USER_APP[\'{}\']'.format(key))


def merge_settings_dicts(a, b, path=None, overwrite_conflicts=True):
"""merges b into a, modify a in place

Found at http://stackoverflow.com/a/7205107/1472229
"""
if path is None:
path = []
for key in b:
if key in a:
if isinstance(a[key], dict) and isinstance(b[key], dict):
merge_settings_dicts(a[key], b[key], path + [str(key)], 
overwrite_conflicts=overwrite_conflicts)
elif a[key] == b[key]:
pass # same leaf value
else:
if overwrite_conflicts:
a[key] = b[key]
else:
conflict_path = '.'.join(path + [str(key)])
raise Exception('Conflict at %s' % conflict_path)
else:
a[key] = b[key]
# Don't let this fool you that a is not modified in place
return a



-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2370e781-b2a6-404e-b943-b96892b49137n%40googlegroups.com.

Re: How reload django settings on run RestService

['Adam Johnson' via Django developers (Contributions to Django itself)]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/stable/faq/help/ . This will help you
find people who are willing to support you, and to ask your question in a
way that makes it easy for them to answer.

Thanks for your understanding and all the best,

Adam

On Mon, Oct 31, 2022 at 1:16 PM Lakhvinder Singh 
wrote:

> i try it
>
> https://github.com/sunscrapers/djoser/blob/master/djoser/conf.py
>
>  user->settings.py use for settings load on global
>
> from copy import deepcopy
>
> from django.core.exceptions import ImproperlyConfigured
> from django.conf import settings
>
>
> default_settings = {
> 'SEND_ACTIVATION_EMAIL': False,
> 'SEND_CONFIRMATION_EMAIL': False,
> 'SET_PASSWORD_RETYPE': False,
> 'SET_USERNAME_RETYPE': False,
> 'PASSWORD_RESET_CONFIRM_RETYPE': False,
> 'PASSWORD_RESET_SHOW_EMAIL_NOT_FOUND': False,
> 'ROOT_VIEW_URLS_MAPPING': {},
> 'PASSWORD_VALIDATORS': [],
> 'SERIALIZERS': {
> 'activation': 'user.serializers.ActivationSerializer',
> 'login': 'user.serializers.LoginSerializer',
>
> },
> 'LOGOUT_ON_PASSWORD_CHANGE': False,
> }
>
>
> def get(key):
> user_settings = merge_settings_dicts(
> deepcopy(default_settings), getattr(settings, 'USER_APP', {}))
> try:
> return user_settings[key]
> except KeyError:
> raise ImproperlyConfigured('Missing settings:
> USER_APP[\'{}\']'.format(key))
>
>
> def merge_settings_dicts(a, b, path=None, overwrite_conflicts=True):
> """merges b into a, modify a in place
>
> Found at http://stackoverflow.com/a/7205107/1472229
> """
> if path is None:
> path = []
> for key in b:
> if key in a:
> if isinstance(a[key], dict) and isinstance(b[key], dict):
> merge_settings_dicts(a[key], b[key], path + [str(key)],
> overwrite_conflicts=overwrite_conflicts)
> elif a[key] == b[key]:
> pass # same leaf value
> else:
> if overwrite_conflicts:
> a[key] = b[key]
> else:
> conflict_path = '.'.join(path + [str(key)])
> raise Exception('Conflict at %s' % conflict_path)
> else:
> a[key] = b[key]
> # Don't let this fool you that a is not modified in place
> return a
>
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2370e781-b2a6-404e-b943-b96892b49137n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM37vqxMJyx4VAch_QV3icNmKBc692XpwnXHQYNY9Mn5bw%40mail.gmail.com.

Re: #21978 include production-ready web server

[Peter Baumgartner]

Hey Tobias! Not using DJANGO_SETTINGS_MODULE is due to my personal dislike
of it :)
I don't like the idea of a totally different Python file getting imported
based on an environment variable and I feel like having different Python
files for each environment isn't a great pattern. I think it is easier to
have major deviations between environments that aren't ever tested until
that environment is reached. I don't love Python being the language for
this type of configuration. I think something static like toml/yaml (or env
vars in a pinch) is easier to reason about, easier to dynamically generate,
and ultimately needs to be used if you want to avoid hard-coding secrets in
your repo.

All that being said, I realize the difference is subtle and goes against
the grain of what's already there. I'm willing to go whatever route makes
it easiest to get accepted.

On Sat, Oct 29, 2022 at 6:02 PM 'Tobias McNulty' via Django developers
(Contributions to Django itself)  wrote:

> Hi Pete,
>
> A pluggable backend sounds like a good idea.
>
> Regarding DJANGO_ENV, why not ship the template with two settings files
> and use the existing DJANGO_SETTINGS_MODULE, instead of adding a new
> environment variable?
>
> Maybe that would be controversial too, I'm not sure, but perhaps less so
> than introducing a new paradigm? In any event, perhaps a pluggable backend
> would allow everyone to be happy, or very nearly so... 😅
>
> To be clear, I'm fully in support of this, no matter how it ends up.
> Providing a decent production-capable server and some sane
> settings/configuration defaults for people to work from -- rather than
> having to scour the documentation for every mention of a production
> environment and figure out how to make those changes by hand -- will be a
> big win IMO. As it stands, first time users might reasonably assume they
> should use Apache to deploy to production (maybe they should, I'm not
> sure...but I haven't seen it done in over a decade):
>
> "We’ve included this with Django so you can develop things rapidly,
> without having to deal with configuring a production server – such as
> Apache – until you’re ready for production."
>
> https://docs.djangoproject.com/en/4.1/intro/tutorial01/
>
> Cheers,
> Tobias
>
> On Sat, Oct 29, 2022, 7:15 PM Peter Baumgartner 
> wrote:
>
>>
>>
>> On Sat, Oct 29, 2022 at 10:06 AM Peter Baumgartner 
>> wrote:
>>
>>> Thanks for the thorough review Florian! Some comments inline...
>>>
>>> On Wed, Oct 26, 2022 at 1:30 AM Florian Apolloner 
>>> wrote:
>>>
 Hi Pete,

 this does look interesting. And I agree that this is something that
 would be nice to have in core in one form or another. That said I think we
 have to do it iteratively (ie in smaller parts) and evaluate along the way.

>>>
>>> Agreed. I think adding the additional settings with some sort of
>>> production switch is the least obtrusive place to start.
>>>
>>>

 Since you asked for feedback, I'll tell you what I'd do differently
 (and this is also a sign that production environment vary widely).

>>>
>>> Production environments do vary widely, but I don't think that should
>>> stop us from providing defaults that are one-size-fits-most. startproject
>>> already does this and users are welcome to adjust it how they see fit.
>>>
>>>

  * As soon as health checks check something aside from simply returning
 a 200 status code I'd want to be able to limit access to them

>>>
>>> Yep, that seems reasonable. Although depending on the level of failure,
>>> you may not be able to log in to see them. Starting with just a view that
>>> responds with a 200 is reasonable.
>>>
>>>
  * I like my dev env to be as close as possible to production so I
 usually also use whitenoise in dev. I had to many times where dev worked
 and whitenoise in prod failed then :D

>>>
>>> Also a good point... I'll add that.
>>>
>>>
  * I do hate `DJANGO_ENV` but I guess there is no way around it.
 Currently my projects often piggy-back on DEBUG but that can be rather hard
 from time to time

>>>
>>> I'm open to other suggestions here, but am kind of in the same boat.
>>> There may be times when you briefly want DEBUG=True in a non-public
>>> deployed environment or DEBUG=False in a development environment.
>>> Overloading that makes those scenarios a challenge.
>>>
>>>
  * I prefer settings in settings files (ini/yaml/toml) as opposed to
 env variables that leak down the whole process-tree. django-environ does
 support this; that said there are other options like dynaconf which also
 support hashicorp vault which is a massive plus imo. Just being able to
 utilize vault for free from every django application out there would be
 stellar.

>>>
>>> I'm 100% in agreement here. I wrote goodconf [1] for this before I knew
>>> about dynaconf which does a lot of the same things. I would love to see
>>> Django adopt a split between "settings" (

Re: #21978 include production-ready web server

[Peter Baumgartner]

On Sun, Oct 30, 2022 at 7:57 AM Florian Apolloner 
wrote:

> Hi Peter,
>
> On Saturday, October 29, 2022 at 6:07:16 PM UTC+2 pe...@lincolnloop.com
> wrote:
>
>> Since you asked for feedback, I'll tell you what I'd do differently (and
>>> this is also a sign that production environment vary widely).
>>>
>>
>> Production environments do vary widely, but I don't think that should
>> stop us from providing defaults that are one-size-fits-most. startproject
>> already does this and users are welcome to adjust it how they see fit.
>>
>
> Agreed, I should have written this better. I expect there to be plenty of
> different opinions on this topic and it might be hard to figure out the
> one-size-fits-most without being to limiting.
>
>
>> * As soon as health checks check something aside from simply returning a
>>> 200 status code I'd want to be able to limit access to them
>>>
>>
>> Yep, that seems reasonable. Although depending on the level of failure,
>> you may not be able to log in to see them. Starting with just a view that
>> responds with a 200 is reasonable.
>>
>
> Sure and with limiting access I was more thinking about source IPs than
> actual logins (ie open health endpoint to the internal network from which
> the loadbalancer connects)
>
>
>>  * I do hate `DJANGO_ENV` but I guess there is no way around it.
>>> Currently my projects often piggy-back on DEBUG but that can be rather hard
>>> from time to time
>>>
>>
>> I'm open to other suggestions here, but am kind of in the same boat.
>> There may be times when you briefly want DEBUG=True in a non-public
>> deployed environment or DEBUG=False in a development environment.
>> Overloading that makes those scenarios a challenge.
>>
>
> Jupp, that is also the reason why I am in a love/hate relationship with it
> :)
>
>
>>  * I prefer settings in settings files (ini/yaml/toml) as opposed to env
>>> variables that leak down the whole process-tree. django-environ does
>>> support this; that said there are other options like dynaconf which also
>>> support hashicorp vault which is a massive plus imo. Just being able to
>>> utilize vault for free from every django application out there would be
>>> stellar.
>>>
>>
>> I'm 100% in agreement here. I wrote goodconf [1] for this before I knew
>> about dynaconf which does a lot of the same things. I would love to see
>> Django adopt a split between "settings" (which I see as things that don't
>> change across environments) and "configuration" (things that you set per
>> environment). I did switch to django-environ's FileAwareEnv [2] which
>> allows loading from files, but not in the yaml./toml sense. I didn't go all
>> in here because I felt like it was a more controversial stance and at the
>> end of the day, you probably still need to support environment variables
>> because many (most?) PaaS providers don't have support for files like that.
>>
>
> Yes, being able to override stuff via env variables should probably be
> always allowed. And as long as we do have a "schema" of some kind (be that
> via config.get_bool or typing annotation on a configuration object) it is
> also relatively easy to convert env variables to their correct form (ie
> boolean).
>
> With the goal of getting something merged into Django eventually, I felt
>> like environment variables were the lowest bar. We have precedence for
>> loading from environment variables with DJANGO_SETTINGS_MODULE. Do you
>> think a more full-featured library like dynaconf would make it harder to
>> push some of this upstream? Users that want to use dynaconf or goodconf or
>> whatever can still edit their settings and use those like they do today.
>>
>
> Yes and no. A 3rd party dependency will make it certainly harder to get
> this merged upstream. On the other hand I wouldn't want to support env
> variables only in the first iteration if that makes adding support for
> "properly" typed schemes (yaml/toml) harder in the future. From a viability
> point I'd like to see that we have an API that can handle hierarchical
> typed config and env variables. If we get that right the reasons to use
> something else will be rather small I guess.
>
> > Had another thought here... what about providing a pluggable
> configuration backend? Django could ship with some native backends like
> environment variables and toml (when it's available). Third party packages
> could provide Vault, secret files, etc. Same as how storages currently
> works and how you can easily drop in something like django-storages.
>
> Yes, the main question though is how the api contract would look like and
> how we are going to "solve" the chicken egg problem of how those backends
> are activated? We cannot really put `SETTING_LOADERS =
> ["django.settings.loaders.env", "django.settings.loader.toml"]` into a
> `settings.py` file and then use `config.get("DATABASE_URL")` just below to
> use the DATABASE_URL. So like `DJANGO_SETTINGS_MODULE` this would be
> something that has to be in an env var before Djang

Re: #21978 include production-ready web server

[Florian Apolloner]

On Monday, October 31, 2022 at 5:27:02 PM UTC+1 pe...@lincolnloop.com wrote:

> In my ideal scenario, the default is a hard-coded settings file for the 
> project (deprecating DJANGO_SETTINGS_MODULE env var) and we have 
> CONFIG_LOADERS defined in the settings that could do env, toml, etc. 
> Perhaps things like django.setup, 
>
django.core.wsgi.get_wsgi_application, and 
> django.core.management.execute_from_command_line could accept the settings 
> module as an argument? django-admin could accept a --settings flag?
>

I doubt that will ever fly. There is no project so to say in Django. 
Currently literally everything depends on knowing a 
`DJANGO_SETTINGS_MODULE` from which everything else can follow (even the 
wsgi app…). So without a settings file how would you know that hard-coded 
path for it? Django has no concept of a project that you could import. You 
also cannot easily put `CONFIG_LOADERS` in a settings file like we 
currently have because then how are you going to evaluate that while also 
executing all the other module level stuff. And django-admin command all 
already support a `--settings` flag (as alternative to 
DJANGO_SETTINGS_MODULE ;))

Either way I doubt we will deprecating DJANGO_SETTINGS_MODULE any time 
soon. And I don't see it such of a problem with being there. Projects can 
set it (and startproject already does this) to a fixed value in manage.py & 
wsgi.py. For a project that installs a custom entrypoint script, you can 
also preset it to whatever you like.

Please note that we are trying to load stuff from files & env vars in the 
first step, not throw out settings.py at the same time…

Cheers,
Florian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b0cc8e42-0781-4a69-b8a1-12cc6929c2f7n%40googlegroups.com.

Re: #21978 include production-ready web server

[Peter Baumgartner]

On Mon, Oct 31, 2022 at 11:52 AM Florian Apolloner 
wrote:

> On Monday, October 31, 2022 at 5:27:02 PM UTC+1 pe...@lincolnloop.com
> wrote:
>
>> In my ideal scenario, the default is a hard-coded settings file for the
>> project (deprecating DJANGO_SETTINGS_MODULE env var) and we have
>> CONFIG_LOADERS defined in the settings that could do env, toml, etc.
>> Perhaps things like django.setup,
>>
> django.core.wsgi.get_wsgi_application, and
>> django.core.management.execute_from_command_line could accept the settings
>> module as an argument? django-admin could accept a --settings flag?
>>
>
> I doubt that will ever fly. There is no project so to say in Django.
> Currently literally everything depends on knowing a
> `DJANGO_SETTINGS_MODULE` from which everything else can follow (even the
> wsgi app…). So without a settings file how would you know that hard-coded
> path for it? Django has no concept of a project that you could import. You
> also cannot easily put `CONFIG_LOADERS` in a settings file like we
> currently have because then how are you going to evaluate that while also
> executing all the other module level stuff. And django-admin command all
> already support a `--settings` flag (as alternative to
> DJANGO_SETTINGS_MODULE ;))
>
> Either way I doubt we will deprecating DJANGO_SETTINGS_MODULE any time
> soon. And I don't see it such of a problem with being there. Projects can
> set it (and startproject already does this) to a fixed value in manage.py &
> wsgi.py. For a project that installs a custom entrypoint script, you can
> also preset it to whatever you like.
>
> Please note that we are trying to load stuff from files & env vars in the
> first step, not throw out settings.py at the same time…
>

I figured it wouldn't fly :)

I misunderstood your chicken-egg question above. What I've been doing is
defining a "Config" class and instantiating it in the settings file.
Instantiation of the class (or calling an explicit method on it) would do
the env/file loading and the instance becomes your `env` object. Rather
than having a CONFIG_LOADERS setting, you could define them on the Config
class or when you instantiate it. This is pretty similar to how goodconf
works today. https://github.com/lincolnloop/goodconf#quick-start


>
> Cheers,
> Florian
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/b0cc8e42-0781-4a69-b8a1-12cc6929c2f7n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6K9znR0RwrW%2B9SVMOy56mg%3DOuAYafBExGJf8n-TFdefhhKeA%40mail.gmail.com.

Django bugfix release: 4.1.3

[Mariusz Felisiak]

Details are available on the Django project weblog:

https://www.djangoproject.com/weblog/2022/nov/01/bugfix-release/

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e19142ab-dc81-974c-cc32-72ef90ae0f6e%40gmail.com.