Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

[Tobias McNulty]

I'm surprised that (as far as I can see) this idea hasn't been discussed in
the ~11 year (!) history of this ticket. It was alluded to ~3 years go by
mkhalil28 , but was
missing the backwards-compatible 'except' bit and didn't get any follow-up
discussion. To me this seems like an appropriate corresponding change to
#25617 .

If I'm thinking through this correctly, this would provide, for all intents
and purposes:

   - case-insensitive usernames for all new sites (and new users on
   existing sites)
   - indefinite backwards compatibility for sites that already have
   "duplicate" usernames in the database, when case is ignored
   - no feature flag that needs to be maintained
   - the added benefit of allowing sites that really want case-sensitive
   usernames to disable this behavior, if needed (by never adding unique=True
   to the username field)

If a change like this has been considered already, I am curious to know why
it was rejected.

I am not suggesting (yet) that we re-open #2273, but I think this would at
least be worth exploring further: What would a minimum-impact change for
case-insensitive usernames look like, both in terms of code and
documentation changes? #25617 + this change seem like a good start, but
more work will certainly be required to get this into a state that's ready
for formal review. I probably won't have time to do that myself in the near
future, but I would be happy to serve as a reviewer.

Tobias



*Tobias McNulty*Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

On Sun, Apr 16, 2017 at 5:47 PM, Info-Screen 
wrote:

> Wouldn't it be possible to implement case-insensitive usernames without
> loosing backwards compatibility, by checking the username iexact and only
> if there are multiple possibilities fall back to the old case-sensitive
> variant?
>
> So something like this:
>
> diff --git a/django/contrib/auth/base_user.py b/django/contrib/auth/base_
> user.py
> index 34dd6ac2f2..748db8bf89 100644
> --- a/django/contrib/auth/base_user.py
> +++ b/django/contrib/auth/base_user.py
> @@ -4,6 +4,7 @@ not in INSTALLED_APPS.
>  """
>  import unicodedata
>
> +from django.core.exceptions import MultipleObjectsReturned
>  from django.contrib.auth import password_validation
>  from django.contrib.auth.hashers import (
>  check_password, is_password_usable, make_password,
> @@ -41,7 +42,14 @@ class BaseUserManager(models.Manager):
>  return get_random_string(length, allowed_chars)
>
>  def get_by_natural_key(self, username):
> -return self.get(**{self.model.USERNAME_FIELD: username})
> +username_field = self.model.USERNAME_FIELD
> +
> +# Try case-insensitive match of username.
> +# If there are multiple possiblities fallback to case-sensitive
> lookup
> +try:
> +return self.get(**{username_field + '__iexac': username})
> +except MultipleObjectsReturned:
> +return self.get(**{username_field: username})
>
>
>  class AbstractBaseUser(models.Model):
>
> --
> 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/cc07fa69-06b3-4d24-aa2c-
> e5201ebe936a%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/CAMGFDKQaa4RX31yJqOapRvehH8GBPObybJmLCJ44JqT0OZpqFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Feature Request] Shorthand syntax for filtering aggregations

[Tom Forbes]

Hey Simon,
Thanks for your reply, I actually agree after thinking about it. Adding a
filter/exclude method and getting it to work correctly in the way people
would expect is be pretty complex. Adding an argument that takes a Q object
would suffice for now at least.

I'm happy to implement this, but any advice (however brief) on how to would
be much appreciated! The base Aggregate class uses the Func `as_sql` (and
I'm assuming we want to keep it like that), but I'm not sure how to support
this parameter without a custom `as_sql` on the Aggregate class. The reason
being is that the FILTER syntax appears outside of the aggregate, whereas
the CASE syntax appears inside.

Perhaps I am over thinking things though. I could override the `as_sql` in
the Aggregate class to check if the database supports FILTER, and if so
just tack `FILTER (WHERE ...)` on the end of the produced sql. If it
doesn't support FILTER then I can do what I currently do in the pull
request and munge the source expressions to be a CASE statement before
calling `super().as_sql()`.

Thoughts?


On Mon, Apr 17, 2017 at 5:45 AM, charettes  wrote:

> Hello Tom,
>
> Thanks for working on adding filter support to aggregate. I think adding
> support for the SQL:2003 features on all aggregates by emulating it on
> backends that don't support it using CASE makes a lot of sense[0].
>
> As I've mentioned on your PR this is syntactic sugar I've been missing from
> Django's conditional aggregation API since I was using
> django-aggregate-if[1]
> before #11305 was fixed[2].
>
> Now for the proposed syntax I understand you want to mimic the Queryset's
> API by allowing filter()/exclude() to be chained but I don't think filter
> chaining
> on aggregate is common enough to warrant the extra effort required to make
> it
> work. As I've mentioned previously I'd advocate for a simple `filter`
> kwarg that
> accepts a Q instance instead as it makes it easier to implement and emulate
> the Case() fallback. This also makes the filter() vs filter().filter() for
> multi-valued
> relationships subtleties a non-issue.
>
> Mailbox.objects.annotate(
>read_emails=Count('emails', filter=Q(unread=False)),
>unread_emails=Count('emails', filter=Q(unread=True)),
>recent_emails=Count('emails', filter=Q(received_date__lt=one_week_ago)),
> )
>
>
> Cheers,
> Simon
>
> [0] http://modern-sql.com/feature/filter
> [1] https://pypi.python.org/pypi/django-aggregate-if
> [2] https://code.djangoproject.com/ticket/11305
>
> Le mercredi 12 avril 2017 17:31:44 UTC-4, Tom Forbes a écrit :
>>
>> Hello,
>> At the Djangocon sprints I wanted to add support for a postgres specific
>> syntax for filtering aggregations, which is quite simple: MAX(something)
>> FILTER (WHERE x=1).
>>
>> During this the sprints I was told that it would be good to support this
>> for all databases, and it can be done using the CASE syntax: MAX(CASE WHEN
>> x=1 THEN something END).
>>
>> Doing this with the ORM is quite verbose, it would be really nice to be
>> able to have a shorthand syntax for filtering aggregates that can use
>> database-specific syntax where available (the postgres syntax is faster
>> than the CASE syntax). I've made a proof of concept merge request that
>> implements this here:
>>
>> https://github.com/django/django/pull/8352
>>
>> I'd really like some feedback and to maybe have a discussion about what
>> the API could look like. Currently I went for adding `.filter()` and
>> `.exclude()` methods to the base Aggregate class. I like this approach as
>> it's close to the familiar queryset syntax but I understand there are
>> subtleties with combining them (I just AND them together currently). It's
>> also better to be consistent - if we can't support all of the queryset
>> filter() syntax then we shouldn't confuse people by having a filter method
>> that acts differently.
>>
>> An example of the API is this:
>>
>> Mailboxes.objects.annotate(
>>read_emails=Count('emails').filter(unread=False),
>>unread_emails=Count('emails').filter(unread=True),
>>recent_emails=Count('emails').filter(received_date__lt=one_week_ago)
>> )
>>
>>
>> I'd really like some feedback on what the API should look like. Is filter
>> a good idea? Any feedback on the current merge request implementation is
>> appreciated as well, I'm fairly new to the Django expression internals. I
>> think I'm going the right way with having a separate FilteredAggregate
>> expression but I'm not sure.
>>
>> Many thanks,
>> Tom
>>
> --
> 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/
> msg

Re: [Feature Request] Shorthand syntax for filtering aggregations

[charettes]

Hey Tom,

Overriding Aggregate.as_sql() to branch on connection.features to build the
FILTER clause shouldn't be an issue.

I think you could rely on super().as_sql(..., filter=filter_sql) extra 
parameter when the
connection supports the FILTER statement and fallback to self.clone(), 
clone.source_expressions[0]
wrapping in a Case(When) and return clone.as_sql(...) when it's not the 
case.

Don't hesitate to @mention me on Github if you'd like extra pointers. There 
is other
contributors more familiar with the expression API than I am but I think I 
have enough
knowledge to shepperd you through this patch.

Cheers,
Simon

Le lundi 17 avril 2017 10:52:36 UTC-4, Tom Forbes a écrit :
>
> Hey Simon,
> Thanks for your reply, I actually agree after thinking about it. Adding a 
> filter/exclude method and getting it to work correctly in the way people 
> would expect is be pretty complex. Adding an argument that takes a Q object 
> would suffice for now at least.
>
> I'm happy to implement this, but any advice (however brief) on how to 
> would be much appreciated! The base Aggregate class uses the Func `as_sql` 
> (and I'm assuming we want to keep it like that), but I'm not sure how to 
> support this parameter without a custom `as_sql` on the Aggregate class. 
> The reason being is that the FILTER syntax appears outside of the 
> aggregate, whereas the CASE syntax appears inside. 
>
> Perhaps I am over thinking things though. I could override the `as_sql` in 
> the Aggregate class to check if the database supports FILTER, and if so 
> just tack `FILTER (WHERE ...)` on the end of the produced sql. If it 
> doesn't support FILTER then I can do what I currently do in the pull 
> request and munge the source expressions to be a CASE statement before 
> calling `super().as_sql()`.
>
> Thoughts?
>
>
> On Mon, Apr 17, 2017 at 5:45 AM, charettes  > wrote:
>
>> Hello Tom,
>>
>> Thanks for working on adding filter support to aggregate. I think adding
>> support for the SQL:2003 features on all aggregates by emulating it on
>> backends that don't support it using CASE makes a lot of sense[0].
>>
>> As I've mentioned on your PR this is syntactic sugar I've been missing 
>> from
>> Django's conditional aggregation API since I was using 
>> django-aggregate-if[1]
>> before #11305 was fixed[2].
>>
>> Now for the proposed syntax I understand you want to mimic the Queryset's
>> API by allowing filter()/exclude() to be chained but I don't think filter 
>> chaining
>> on aggregate is common enough to warrant the extra effort required to 
>> make it
>> work. As I've mentioned previously I'd advocate for a simple `filter` 
>> kwarg that
>> accepts a Q instance instead as it makes it easier to implement and 
>> emulate
>> the Case() fallback. This also makes the filter() vs filter().filter() 
>> for multi-valued
>> relationships subtleties a non-issue.
>>
>> Mailbox.objects.annotate(
>>read_emails=Count('emails', filter=Q(unread=False)),
>>unread_emails=Count('emails', filter=Q(unread=True)),
>>recent_emails=Count('emails', filter=Q(received_date__lt=one_week_ago)),
>> )
>>
>>
>> Cheers,
>> Simon
>>
>> [0] http://modern-sql.com/feature/filter
>> [1] https://pypi.python.org/pypi/django-aggregate-if
>> [2] https://code.djangoproject.com/ticket/11305
>>
>> Le mercredi 12 avril 2017 17:31:44 UTC-4, Tom Forbes a écrit :
>>>
>>> Hello,
>>> At the Djangocon sprints I wanted to add support for a postgres specific 
>>> syntax for filtering aggregations, which is quite simple: MAX(something) 
>>> FILTER (WHERE x=1).
>>>
>>> During this the sprints I was told that it would be good to support this 
>>> for all databases, and it can be done using the CASE syntax: MAX(CASE WHEN 
>>> x=1 THEN something END).
>>>
>>> Doing this with the ORM is quite verbose, it would be really nice to be 
>>> able to have a shorthand syntax for filtering aggregates that can use 
>>> database-specific syntax where available (the postgres syntax is faster 
>>> than the CASE syntax). I've made a proof of concept merge request that 
>>> implements this here:
>>>
>>> https://github.com/django/django/pull/8352
>>>
>>> I'd really like some feedback and to maybe have a discussion about what 
>>> the API could look like. Currently I went for adding `.filter()` and 
>>> `.exclude()` methods to the base Aggregate class. I like this approach as 
>>> it's close to the familiar queryset syntax but I understand there are 
>>> subtleties with combining them (I just AND them together currently). It's 
>>> also better to be consistent - if we can't support all of the queryset 
>>> filter() syntax then we shouldn't confuse people by having a filter method 
>>> that acts differently.
>>>
>>> An example of the API is this:
>>>
>>> Mailboxes.objects.annotate(
>>>read_emails=Count('emails').filter(unread=False),
>>>unread_emails=Count('emails').filter(unread=True),
>>>recent_emails=Count('emails').filter(received_date__lt=one_week_ago)
>>> )
>>>
>>>
>>> I'd reall

Re: Feature idea: forms signals

[David Seddon]

Hi JP,

That's a good point, sorry I didn't make it clear.

The fork is installed from within the requirements file but you can also 
see it here, on the ticket_27923 
branch: https://github.com/seddonym/django/tree/ticket_27923

I've updated the README to help.

I'd be interested to hear if anyone thinks it's worth me making a pull 
request for this.

David

On Sunday, 16 April 2017 23:59:31 UTC+1, jp...@yourlabs.org wrote:
>
> Hello David,
>
> Is it possible to try to use it as part of the Django fork you mention, 
> instead of the app ?
>
> I couldn't find any link on your github profile, your website and google 
> but perhaps I've missed it.
>
> Thanks !
>
> Best
> <3
>

-- 
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/d4904940-91be-4f65-a16d-d39de1ffc382%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[David Seddon]

Hi Jamesie,

I recently proposed adding a post_init signal for forms 
(https://groups.google.com/forum/#!topic/django-developers/SviNiWy3Bjc).

Here's an example of how you might adjust the 
forms: 
https://github.com/seddonym/formsignals/blob/master/formsignals/priority/receivers.py

If such a signal existed, I think you could use that to adjust widgets, 
fields etc. from a different app. You could even create a third party 
module which implemented a way of overriding this stuff using the settings 
you propose.

If you think it might be useful, then it might be worth saying so on the 
forms signals feature thread?

David


On Sunday, 16 April 2017 23:18:13 UTC+1, Jamesie Pic wrote:
>
> Ooops yes this is correct, it doesn't work in the advised file, apps.py 
>
> Thank you so much for your feedback, I need to ditch this patch just 
> find a way to make Django default usable date, time, image, relations 
> form fields useable ootb by marrying a JS framework. 
>
> Best 
> <3 
>

-- 
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/6d663725-55a8-4d9e-b0e2-a84b741ad65b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26369: default formfield callback override

[Jamesie Pic]

Hi David,

Yep, I'm with you on this, another good reason to close this PR. I'm
building DAL's next feature on your fork, so you'll have my feedback
for sure at some point ;)

Best
<3

-- 
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/CAC6Op18XCRC3Kj328OX0-0UqPMtwkQtu7O3p88Kgc%3De%3DGEHcdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: I would like to discuss my proposal for a working way to call .add() on an m2m with through= model

[Luis Masuelli]

I'm quite happy to see the topic is at least being considered! <3.

Although I suggested a solution, I like the solution posted by Collin in 
the PR (I'd prefer solutions not involving signature changes in methods, 
but anyway those signature changes Colin posted are not so... obtrusive).

I'd like to, however, propose a little change in Collin's code. Immediately 
before this code in _add_items:

self.through(**dict(through_defaults, **{
'%s_id' % source_field_name: 
self.related_val[0],
'%s_id' % target_field_name: obj_id,
}))

This one:

if callable(through_defaults):
through_defaults = 
through_defaults(self.related_val[0], obj_id)

With these two lines, we could allow passing a callable to through_fields 
(as we pass callables for defaults in django fields). The return value of 
such callable should be a dictionary, while the arguments should be source 
and target ids.

But even if this little change is not implemented, I like the Collin's 
solution anyway.

Another subtopic to discuss is about enhancing the Collin's solution, is to 
allow through_defaults be specified on field definition (In the same way we 
define default values in... scalar... fields; I leave open the discussion 
on whether such value should be overriden when using add, create, or any of 
these methods as changed by Collin).

I like how this is going and hope that any solution (even if it is just the 
as-is solution provided by Collin, with no changes) be accepted in any 
near-future version <3.

El martes, 21 de marzo de 2017, 20:29:33 (UTC-5), Alex Hill escribió:
>
> Here's a little bit more historical discussion on the topic: 
> *https://groups.google.com/d/topic/django-developers/uWe31AjzZX0/discussion 
> *
>
> On Wed, 22 Mar 2017 at 05:57 Russell Keith-Magee  > wrote:
>
>> On Tue, Mar 21, 2017 at 2:37 PM, Adam Johnson > > wrote:
>>
>>> It does seem like a somewhat arbitrary historical restriction. Collin's 
>>> PoC change is surprisingly small and simple.
>>>
>>> Seems like it would be fine if Django allowed add() and let any errors 
 about missing data bubble-up.

>>>  
>> As the person who *made* the “somewhat arbitrary historical restriction”… 
>> :-)
>>
>> Honestly - the reason it was made was scope creep. 
>>
>> I was trying to land Eric’s work on #6095, which was already moderately 
>> complex. Nobody disagreed that adding an object to an m2m with a through 
>> model was a *bad* idea - there were just a few design decisions that had to 
>> be made. But if we made those decisions, #6095 was going to take *another* 
>> couple of months to land; the perfect being the enemy of the good, we 
>> decided to limit scope and land “simple” m2m add, and revisit the issue 
>> later.
>>
>> I guess now is “later”… :-)
>>
>> Yours,
>> Russ Magee %-)
>>
>> -- 
>> 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/CAJxq849m632K%3DaMfXGBtF%3DhMXFS9ujzU6xfUzNxSRkkN_UrkqQ%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/a32cf6ae-324a-40c1-b9d9-31bd43af2c2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ticket 2273: django.contrib.auth.models.User: username is case-sensitive

[Info-Screen]

I might be able to try to implement this. I'm new to django, but let's try

On Monday, April 17, 2017 at 4:13:23 PM UTC+2, Tobias McNulty wrote:
>
> I'm surprised that (as far as I can see) this idea hasn't been discussed 
> in the ~11 year (!) history of this ticket. It was alluded to ~3 years go 
> by mkhalil28 , but 
> was missing the backwards-compatible 'except' bit and didn't get any 
> follow-up discussion. To me this seems like an appropriate corresponding 
> change to #25617 .
>
> If I'm thinking through this correctly, this would provide, for all 
> intents and purposes:
>
>- case-insensitive usernames for all new sites (and new users on 
>existing sites)
>- indefinite backwards compatibility for sites that already have 
>"duplicate" usernames in the database, when case is ignored
>- no feature flag that needs to be maintained
>- the added benefit of allowing sites that really want case-sensitive 
>usernames to disable this behavior, if needed (by never adding unique=True 
>to the username field)
>
> If a change like this has been considered already, I am curious to know 
> why it was rejected.
>
> I am not suggesting (yet) that we re-open #2273, but I think this would at 
> least be worth exploring further: What would a minimum-impact change for 
> case-insensitive usernames look like, both in terms of code and 
> documentation changes? #25617 + this change seem like a good start, but 
> more work will certainly be required to get this into a state that's ready 
> for formal review. I probably won't have time to do that myself in the near 
> future, but I would be happy to serve as a reviewer.
>
> Tobias
>
>
>
> *Tobias McNulty*Chief Executive Officer
>
> tob...@caktusgroup.com 
> www.caktusgroup.com
>
> On Sun, Apr 16, 2017 at 5:47 PM, Info-Screen  > wrote:
>
>> Wouldn't it be possible to implement case-insensitive usernames without 
>> loosing backwards compatibility, by checking the username iexact and only 
>> if there are multiple possibilities fall back to the old case-sensitive 
>> variant?
>>
>> So something like this:
>>
>> diff --git a/django/contrib/auth/base_user.py 
>> b/django/contrib/auth/base_user.py
>> index 34dd6ac2f2..748db8bf89 100644
>> --- a/django/contrib/auth/base_user.py
>> +++ b/django/contrib/auth/base_user.py
>> @@ -4,6 +4,7 @@ not in INSTALLED_APPS.
>>  """
>>  import unicodedata
>>  
>> +from django.core.exceptions import MultipleObjectsReturned
>>  from django.contrib.auth import password_validation
>>  from django.contrib.auth.hashers import (
>>  check_password, is_password_usable, make_password,
>> @@ -41,7 +42,14 @@ class BaseUserManager(models.Manager):
>>  return get_random_string(length, allowed_chars)
>>  
>>  def get_by_natural_key(self, username):
>> -return self.get(**{self.model.USERNAME_FIELD: username})
>> +username_field = self.model.USERNAME_FIELD
>> +
>> +# Try case-insensitive match of username.
>> +# If there are multiple possiblities fallback to case-sensitive 
>> lookup
>> +try:
>> +return self.get(**{username_field + '__iexac': username})
>> +except MultipleObjectsReturned:
>> +return self.get(**{username_field: username})
>>  
>>  
>>  class AbstractBaseUser(models.Model):
>>
>> -- 
>> 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/cc07fa69-06b3-4d24-aa2c-e5201ebe936a%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/e9615283-7a07-49d9-9fae-e3e0c4d23619%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.