Re: Feature proposal: Allow shadowing of abstract fields

[Aron Podrigal]

Hi,

I also think so, that overriding a field should not need any special protection.

But how would you deal with inherited managers on the class that might refer to 
some overridden field that has changed?

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/740e7a43-0398-4a09-9d26-91ebb89c7025%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: Allow shadowing of abstract fields

[Aron Podrigal]

Why should this be treated differently than the general behavior when 
realted_names clash when you have more than one foreign key to the same 
model? So as one would normally do
set the related_name explicitly to some other value.
setting the field to None is just the way of removing a field and has 
nothing more special  related to the auto created reverse field descriptor.
about option 3 I didn't quite understand. can you explain a bit more?

On Monday, February 9, 2015 at 4:25:22 PM UTC-5, Marten Kenbeek wrote:
>
> I'd like some additional opinions on the following:
>
> Say you have the following classes:
>
> class Parent(models.Model):
> cousin_set = models.CharField(max_length=100)
>
> class Meta:
> abstract = True
>
> class Child(Parent):
> pass
>
> class Cousin(models.Model):
> child = models.ForeignKey(Child)
>
> Obviously, the `cousin_set` field inherited from `Parent` clashes with the 
> reverse relation from `Cousin`. 
>
> I can see the following options:
> 1) Allow the reverse object descriptor to overwrite the field. 
> 2) Only allow the reverse object descriptor to overwrite the field if it 
> is explicitly set to None on the target model.
> 3) Only allow the reverse object descriptor to overwrite the field if the 
> foreignkey/m2m/o2o field itself has a flag set to explicitly override.
>
> 1) is consistent with the behaviour of local fields, but I think it will 
> be problematic if *other *models can silently overwrite a field. 3) would 
> still allow other models to affect local fields, but at least it has a 
> fail-safe that prevents you from accidentally overriding fields. 2) would 
> only allow the inheriting model itself to change which fields it inherits. 
>
> Problems caused by option 1) would be hard to debug when you don't know 
> which code overrides your field, so I wouldn't do that. I think 2) would be 
> the cleanest and most consistent way. Only local fields would override 
> parent fields, but the sentinel value `None` would remove the field and 
> free the name for reverse relations. I can also see the advantage of 3) 
> over 2) when you don't have access to the model on the other side. However, 
> I don't know enough about foreign key internals to know if 3) is at all 
> feasible. What happens e.g. when only the target is loaded in a migration? 
> Would it pick up that the remote foreign key overrides a local field? As 
> adding reverse relations is a lazy, or at least delayed operation afaik, 
> would it still be save to rely on that to override fields?
>
> I believe my current plans for the patch would automatically create 
> situation 2 without any extra work. The field would no longer exist on the 
> child class when the reverse relation is added. Option 3) would require an 
> additional patch to the code that adds the reverse relationship, but it 
> allows for some extra options.
>
> Any input? Additional options are also welcome. 
>
> Op zondag 8 februari 2015 21:09:41 UTC+1 schreef Marten Kenbeek:
>>
>> The general reaction seems to be a yes if we can work out the kinks, so I 
>> went ahead and created a ticket: 
>> https://code.djangoproject.com/ticket/24305
>>
>> @Aron That's a good question. One option would be to lock certain fields, 
>> so that they can't be changed if they are an integral part of the model. 
>> That would be a simple solution, but that won't help for existing code that 
>> doesn't lock the fields. It won't break existing code, but it won't protect 
>> for errors either. The opt-in version (i.e. an 'unlock' attribute) would 
>> lock many fields which would otherwise be completely safe to overwrite. 
>>
>> Another option would be more elaborate "requirements" for a manager or 
>> some methods, i.e. allow the manager to specify the necessary class of a 
>> certain field or a minimum length. If the modeldoesn't meet the 
>> requirements, the manager or some of the methods will not be inherited. 
>> While it allows for more control, this option would greatly increase the 
>> complexity of the patch and requires more from the developers of custom 
>> managers. It can also cause issues when the requirements aren't up-to-date 
>> with the manager's methods. 
>>
>> We could also say that it is the users responsibility and don't provide 
>> special protection, in line with the fields themselves, but I guess that 
>> this would generally be more problematic for custom managers. It can also 
>> cause silent bugs when the manager's methods don't work as intended but 
>> won't raise an exception either, which is not a good idea imho. 
>>
>> I think the locking approach would be the easiest and most pragmatic 
>> method. I think it's still - in part - the users responsibility to confirm 
>> that a field can be overridden. The Django documentation could, where 
>> applicable, document the requirements on fields that can be overridden, 
>> i.e. that an AbstractUser's username must be a CharField (which isn't 
>> necessarily true, just an

RE Composite fields-/ Multi Primary / Foreign keys

[Aron Podrigal]

Hi, I just came across a project that requires  this functionality of multi 
primary/foreign keys. So I'm bumping up this thread 
again.
 
There were a lot of changes in django and the db api hasre-factored  since 
this topic was discussed. It might be a time for another start on this 
project. I'm willing to work on this as long it is ok with the core 
developers. I didn't have much time yet to spend on this. I'm still reading 
through the other earlier threads on possible implementations.
I will post my proposal for this over the weekend. In the meantime I would 
like to get some feedback from the community. 

Aron.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a4a31a7b-4759-4006-a280-34d9ac6b0abe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: RE Composite fields-/ Multi Primary / Foreign keys

[Aron Podrigal]

yeah, turns out I got busy with some other work and did not have time to work 
on this. Fortunately, Thomas has done a lot of great work yet. I'll just follow 
up on that thread.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e6c3eea7-79fd-4a1e-8cb4-ecad9bde042d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composite fields

[Aron Podrigal]

Hi Thomas,

First, thanks for your work. I've had a plan to start working on this 
feature last week,
but I got too many things to work on with higher priority, Thankfully you 
opted for this, again Thanks.

just sharing my thoughts,

1)  I like the MoneyField model style definition.

2) I don't like the inline declaration, I would opt for Anssi's proposal.

3) as Aymeric mentioned, NOT NULL only makes sense for a real column on the 
database, so that should be only be handled on the SubFields.
Assigning python `None' to the CompositeField should be handled by the 
value_from_dict method.

4) querying syntax, sounds fare. However depending on how we decide on 
exposing the subfields through the Model Meta API, 
eg. if the subfields would be returned by default, then we should also 
allow directly querying of the subfield.

Aron


On Saturday, March 7, 2015 at 6:31:53 AM UTC-5, Aymeric Augustin wrote:
>
> Hello Thomas, 
>
> It’s hard for me to digest a two-page-long email on a complex topic during 
> the week. I bookmarked your first email when it came in. It’s Saturday, 
> 11am, 
> and I dedicated my first chunk of quality brain time to reading the entire 
> thread. I’ll let you ponder what the effect of your second email was. 
>
> In fact, if you propose something stupid, you’ll get a quick answer, 
> because 
> it’s easy to explain. Not getting answers right now means that your 
> proposal 
> is good enough to require consideration. Yes, that’s counter-intuitive. 
>
> With that out of the way, here are my thoughts on your proposal. Some 
> overlap 
> with what other people have said in the thread. 
>
> 1) I would find it reassuring if you described the landscape of past 
> attempts, 
> what good ideas you’re keeping, what bad ideas you’re throwing away — in 
> short, if you convinced us that you’re building on top of past attempts. 
> The 
> main goal of this exercise is to guarantee that you don’t overlook a use 
> case 
> or an argument that made consensus in the past. (Don’t spend too much time 
> on 
> code; it my experience it’s harder to reuse and code matters much less 
> than 
> design. 
>
> 2) The syntax for inline composite fields doesn't look very nice. Could 
> you 
> simplify it somehow? Anssi’s proposal is good. I assume that a composite 
> field 
> could add the subfields to the model class if they aren't defined 
> explicitly 
> and their names passed in arguments to the composite field. 
>
> 3) Have you checked that all the Field APIs make sense for CompositeField? 
> It's quite obvious that value_from/to_dict are needed. It's less obvious 
> that 
> everything else is still needed. 
>
> 4) I'm wary of the extra 'isnull' column. Couldn't we required that, if 
> the 
> composite field is NULL, at least one of the subfields is NULL? My idea is 
> that a nullable composite field would consider itself NULL if all nullable 
> subfields are NULL. Declaring a composite subfield nullable when all 
> subfields 
> are non-nullable would be an error. In your MoneyField example, the amount 
> subfield should be nullable when the composite field is nullable. 
>
> 5) I understand the first two restrictions. They required deeper 
> refactorings 
> to be lifted. The reason for the third one is less clear. Is it just a 
> matter 
> of beating the metaclass into cooperation? 
>
> Best, 
>
> -- 
> Aymeric. 
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e1024af3-2822-4136-979c-7980e8c99dc5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composite fields

[Aron Podrigal]

Hi Thomas, I replied earlier before you posted, looks like my message got 
sent actually a lot later.

having a function like  *models.constrain(x, y, unique=True) *makes sense 
for inline declarations.

About null handling, If all columns on the database are null=True and all 
columns have a null value, then the composite field value would be  `None'. 
Otherwise it would be a dict mapping to the subfields, and a query needs to 
specify the subfields it queries against.


Aron.

On Saturday, March 7, 2015 at 11:16:12 PM UTC-5, Thomas Stephenson wrote:
>
> Aymeric,
>
> Thanks for your input. I feel some of your concerns have been addressed in 
> the DEPs I made, which have included quite a bit of input from this thread 
> along with the original design. That said, some of the points you've raised 
> are new and haven't been raised by other people, so I'll give you a full 
> reply.
>
> 1) That's still something I have to do, but more time consuming than other 
> parts of creating the proposal and I've put it off until I have a while to 
> do it. The original implementation was done without too much consideration 
> of prior attempts, because I was more interested in getting something 
> working than I was in learning from the past. 
>
> 2) I agree. The new syntax I've proposed is to add one or more class-level 
> methods to the django.db.models API. The new syntax for "inline" fields is:
>
> class MyModel(models.Model):
> x = models.IntegerField()
> y = models.IntegerField()
> point = models.constrain(x, y, unique=True)
>
good 

>
> The reason for not using the CompositeField constructor is that a lot of 
> the options which make sense for standalone field constructors (and all the 
> other field classes) make absolutely no sense when you're mainly leveraging 
> composite fields to provide a table level constraint to two existing 
> fields. Also there are some things that are commonly done in practice (like 
> providing `verbose_name` as a positional arg) that make adding multiple 
> leading positional arguments difficult.
>
> Note: It's a shame that we can't use py3's keyword only arguments here.
>
> 3) No, not all the field base API makes sense for composite fields -- in 
> fact most of it doesn't. This is a huge problem with fields in general, not 
> just composite fields -- there's just too much functionality on the basic 
> Field class that assumes a one-to-one mapping between a Field and a 
> database column and too many parameters accepted by field base that only 
> make sense for subsets of the available field types.
>
> e.g. 
> - What does "blank" or "max_length" mean for an IntegerField?
> - What does 'rel' mean for a NullBooleanField?
> - What does get_col mean for a ManyToManyField?
> etc.
>
> To fix this would mean introducing significant backwards incompatible 
> changes and, while I would support such a change, I'm not sure it's a 
> discussion that affects the ability to implement composite fields.
>
> 4) The addition of the `isnull` field is mainly to support the ability to 
> query for whether a composite field is NULL. If we leave it implementation 
> defined as to how to interpret whether a specific configuration of 
> subfields maps to a python `None` value for the composite field, then it 
> becomes really difficult to define lookup transformations to query for null 
> values in the table. 
>
> But although it sounded like a good idea when I came up with it, it raises 
> more questions than it solves. I'm more than ready to go back to the 
> drawing board on that one. 
>
5) Inheritance in the model API is complicated enough as it is without 
> adding inheritance of field types. Yes, it could be supported by "beating 
> the metaclass into submission", but it's not something that I think adds 
> any particular value. I did change the "no subclassing at all" restriction 
> to "only one class in an inheritance heirarchy can define subfields" when 
> writing the DEP though, because Ansarri wants the ability for users to 
> extend ForeignKey with their own python behaviour. 
>
> Thomas
>
>
>
> On 7 March 2015 at 22:31, Aymeric Augustin  > wrote:
>
>> Hello Thomas,
>>
>> It’s hard for me to digest a two-page-long email on a complex topic during
>> the week. I bookmarked your first email when it came in. It’s Saturday, 
>> 11am,
>> and I dedicated my first chunk of quality brain time to reading the entire
>> thread. I’ll let you ponder what the effect of your second email was.
>>
>> In fact, if you propose something stupid, you’ll get a quick answer, 
>> because
>> it’s easy to explain. Not getting answers right now means that your 
>> proposal
>> is good enough to require consideration. Yes, that’s counter-intuitive.
>>
>> With that out of the way, here are my thoughts on your proposal. Some 
>> overlap
>> with what other people have said in the thread.
>>
>> 1) I would find it reassuring if you described the landscape of past 
>> attempts,
>> what good ideas you’re keeping, what b

Re: Feature proposal: Allow shadowing of abstract fields

[Aron Podrigal]

Bumping up on this again, what are the plans for moving this ahead. 

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c83d0040-a6c0-435b-b7c3-1832ec683b32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

created_at / modified_at on all database tables

[Aron Podrigal]

Hi,

I'd like to propose a created_at / modified_at auto field to models so that 
one can just turn this functionality on by a setting in settings.py or 
within the models Meta settings.
I want these fields on both of the OneToOne related models when using 
concrete inheritance, thus using a TimeStampedBaseModel abstract model 
would cause these fields to clash. The reason I need created_at / 
updated_at on every table because Django is not the only app using the 
database I have other services sharing the same database. I assume having 
created_at updated_at fields on tables to be very common. I can imagine 
django creating those fields to all tables implicitly while handling those 
field collisions properly (eg.  When accessing model.created_at on a 
derived class it will return the value of that model. 
model.base_model.created_at would give access to its base model).

What are your thoughts?

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4c2a341f-e9d1-4841-892d-8d72c7688db9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: created_at / modified_at on all database tables

[Aron Podrigal]

The problem is with the field clashes. Consider the following

from django.db import models


class TimeStampedModel(models.Model):
created_at = models.DateTimeField(auto_now_add=True)
updated_at = models.DateTimeField(auto_now=True)

class Meta:
abstract = True


class Member(TimeStampedModel):
member_id = models.CharField(max_length=255)


class EliteMember(Member, TimeStampedModel):
additional_elite_data = models.TextField()


This results in the following system check error.

django.core.management.base.SystemCheckError: SystemCheckError: System 
check identified some issues:

ERRORS:
myapp.EliteMember.created_at: (models.E006) The field 'created_at' clashes 
with the field 'created_at' from model 'myapp.member'.
myapp.EliteMember.updated_at: (models.E006) The field 'updated_at' clashes 
with the field 'updated_at' from model 'myapp.member'.

System check identified 2 issues (0 silenced).



As I mentioned earlier, if EliteMember would not inherit from 
TimeStampedModel, EliteMember   would not have the 'created_at' and  
'updated_at' columns. And I do need that even on the inherited tables. So 
this would require special handling in ModelBase and perhaps while 
executing the queries against the tables.


On Wednesday, September 16, 2015 at 9:36:24 AM UTC-4, Christian Schmitt 
wrote:
>
> I also think that this won't need to be in core since a Model Subclass 
> works. We use this in our Application since we can't hard delete stuff so 
> we overwritten the Model Field and the manager that all tables contain a 
> date_deleted field which will be set when calling delete() objects.delete().
> And the Code was really simple, just create a class that extends 
> models.Model and specifiy it abstract = True and then you can inherit from 
> it in every of your models.
>
> 2015-09-16 13:13 GMT+02:00 Florian Apolloner  >:
>
>> Settings.py is definitely not the way to go. As for Meta options: Feel 
>> free, just do it via your own Model subclass, there is no need for this to 
>> be in core imo.
>>
>> On Wednesday, September 16, 2015 at 7:44:17 AM UTC+2, Aron Podrigal wrote:
>>>
>>> Hi,
>>>
>>> I'd like to propose a created_at / modified_at auto field to models so 
>>> that one can just turn this functionality on by a setting in settings.py or 
>>> within the models Meta settings.
>>> I want these fields on both of the OneToOne related models when using 
>>> concrete inheritance, thus using a TimeStampedBaseModel abstract model 
>>> would cause these fields to clash. The reason I need created_at / 
>>> updated_at on every table because Django is not the only app using the 
>>> database I have other services sharing the same database. I assume having 
>>> created_at updated_at fields on tables to be very common. I can imagine 
>>> django creating those fields to all tables implicitly while handling those 
>>> field collisions properly (eg.  When accessing model.created_at on a 
>>> derived class it will return the value of that model. 
>>> model.base_model.created_at would give access to its base model).
>>>
>>> What are your thoughts?
>>>
>> -- 
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/5693dbd6-e789-4025-8a92-5b491269bf9e%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/5693dbd6-e789-4025-8a92-5b491269bf9e%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a4a3db25-0749-402e-8479-8e9f3f5429a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Inheriting from multiple ABCs do not follow the MRO for its abstract Managers

[Aron Podrigal]

While going through the code for ModelBase for reviewing [1] it is unclear 
to me when inheriting from 2 Abstract models which define Managers, if the 
concrete model should use the first manager according to the creation 
counter or it should follow the MRO. I would expect the following test to 
pass. I would appreciate if someone can confirm that this is a bug so we 
should open a trac ticket and fix this.


@isolate_apps('managers_regress')
def test_multi_abstract_model_inheritance_manager_mro(self):

from django.db.models.manager import Manager

class Manager1(Manager):
pass

class Manager2(Manager):
pass

class AbstractModel1(models.Model):
custom_manager = Manager1()

class Meta:
abstract = True

class AbstractModel2(models.Model):
custom_manager = Manager2()

class ConcreteModel(AbstractModel2, AbstractModel1):
pass

self.assertIsInstance(ConcreteModel.custom_manager, Manager2)
 self.assertIsInstance(ConcreteModel._default_manager, Manager2)

 

-- 
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/8e267ae3-bd78-40d7-aceb-bddb3e98e317%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Need to get user_id outside of a view

[Aron Podrigal]

I've had similar use cases where I needed access to the request in a number
of places. I've come to the conclusion that any code that is expected to
operate under wsgi (and only under wsgi, and not via management commands)
to use thread locals.

see https://github.com/nebstrebor/django-threadlocals

On Sun, Jan 29, 2017, 1:22 PM Victor Porton  wrote:

> Probably a good way to solve this problem is to add `request` (with
> default `None`) argument to `Model.save` method, which could then be passed
> to the storage used for file fields.
>
> Let us discuss if this is a good solution or can we invent something
> better.
>
>
> On Sunday, January 29, 2017 at 8:12:10 PM UTC+2, Victor Porton wrote:
>
> See also
> https://code.djangoproject.com/ticket/27786
>
> I attempt to make file storage behavior dependent on the current user.
> (In fact, I attempted to store the ID of the uploader of a given file
> into the database, so that other users could not list or delete this
> file. Also I tried to store the file in a secret directory (directory
> with a secret hash as its name) so that other users could not read it
> without receiving an explicit link from the uploader.) I wrote code
> like this:
>
> class MyStorage(FileSystemStorage):
> # ...
>
> def get_user(self):
> SessionStore =
> import_module(settings.SESSION_ENGINE).SessionStore
> s = SessionStore()
> s.load()
> # print({id: s[id] for id in s.keys()})  # FIXME
> # user = apps.get_model('User').objects.get(id=s['user_id'])
> return s['user_id']
>
> This is set as
>
> DEFAULT_FILE_STORAGE = 'xxx_storage_app.storage.MyStorage'
>
> So I expect every form with a file to upload using MyStorage (and so
> the upload algorithm depends on the current user).
>
> But s behaves as an empty hash (without user_id element), as revealed
> by the commented "FIXME" line.
>
> We need either to make SessionStore to support this use case or
> massively rewrite API to pass `request` to the form and ultimately to
> the storage. I think we can do this without losing backward
> compatibility using default function arguments.
>
> It is a big API change, but it is necessary to support storage
> dependent on the current user. It is a real and important use case for
> our project.
>
> Let us discuss the details, what is the best way to implement this in
> future versions of Django.
>
> Sorry for an offtopic, but can you advise me how to do it without
> rewriting Django core?
>
> --
> 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/6db56f76-6ac0-4e24-b42b-3c5b800a749d%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/CANJp-yjo5zT9eh4JtPW7aA%3DPXjXGX0xSpHQUA75CSVU%2BhWpMYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.