Re: Making the test suite run faster

[Aymeric Augustin]

On 7 févr. 2015, at 01:02, Russell Keith-Magee  wrote:

> I've thought about (but never done anything) about this problem in the past - 
> my thought for this problem was to use multiple test databases, so you have 
> isolation. Yes this means you need to do more manual setup (createdb 
> test_database_1; createdb test_database_2; etc), but it means you don't have 
> any collision problems multiprocessing an on-disk database.

The fastest way to do this is probably to create a database then clone it. Each 
backend would have to implement a duplication method:

- SQLite: os.copy(‘django_test.sqlite3’, ‘django_test_N.sqlite3’)
- PostgreSQL: CREATE DATABASE django_test_N WITH TEMPLATE django_test OWNER 
django_test;
- MySQL: mysqldump … | mysql …
- Oracle: apparently there’s a DUPLICATE command — I have a bad feeling about 
this one.

For optimal speed, this feature should support --keepdb.

> My only "concern" relates to end-of-test reporting - how are you reporting 
> test success/failure? Do you get a single coherent test report at the end? Do 
> you get progress reporting, or just "subprocess 1 has completed; 5 failures, 
> 200 passes" at the end of a subprocess? My interest here isn't strictly about 
> Django - it's about tooling, and integration of a parallelized test suite 
> with IDEs, or tools like Cricket.

Yes, I have a clean report. If you look at the pull request you’ll see two 
successive implementations:

1) Run tests in workers, pass “events" back to the master process, feed them to 
the master test runner. Unfortunately this technique is never going to be 
sufficiently robust because it involves passing tracebacks between processes 
and tracebacks aren’t pickleable in general.

2) Run tests in worker, buffer the output in workers, have the master test 
runner reconstruct proper output. This is less elegant. It only works with the 
TextTestRunner because it depends heavily on its internals. But it’s more 
robust and it suffices for running Django’s test suite.

What this really means is — you have to choose between being a proper unittest2 
runner or being robust. That’s what I meant when I said the unittest2 APIs made 
the implementation painful.

-- 
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/6732B9C6-3172-4D07-9354-1DDD21AF4100%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Adding missing aggregate functions to contrib.postgres ?

[Andriy Sokolovskiy (coldmind)]

So, since django has contrib.postgres, maybe it would be reasonable to add 
postgres-specific aggregate functions to this module?
If it is good idea, I'm gonna create ticket and implement this.

-- 
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/2d3b2bd2-3bce-4e40-8383-ef5ca328bc26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making the test suite run faster

[Fabio Caritas Barrionuevo da Luz]

Parallel is different than concurrent, did you come to look at the package 
"testtools", I think it implements something similar to what you want to do


https://github.com/testing-cabal/testtools/blob/master/testtools/testsuite.py#L38-L198
http://stackoverflow.com/a/17059844/2975300


Em sexta-feira, 6 de fevereiro de 2015 13:06:02 UTC-3, Aymeric Augustin 
escreveu:
>
> Hello,
>
> As the test suite is growing, it’s getting slower. I’ve tried to make it 
> faster by running tests in parallel.
>
> The current state of my experiment is here: 
> https://github.com/django/django/pull/4063
>
> I’m distributing the tests to workers with the multiprocessing module. 
> While the idea is simple, the unittest APIs make its implementation painful.
>
> ** Results **
>
> Without the patch:
>
> Ran 9016 tests in 350.610s
> ./runtests.py  355,86s user 20,48s system 92% cpu 6:48,23 total
>
> With the patch
>
> Ran 9016 tests in 125.778s
> ./runtests.py --parallel  512,31s user 29,92s system 300% cpu 3:00,73 total
>
> Since it takes almost one minute to create databases, parallelization 
> makes the execution of tests go from 6 minutes to 2 minutes.
>
> This isn’t bad, but the x3 speedup is a bit disappointing given that I 
> have 4 physical / 8 logical cores. Perhaps the IPC is expensive.
>
> Does anyone have insights about scaling with multiprocessing?
>
> ** Limitations **
>
> This technique works well with in-memory SQLite databases. Each process 
> gets its own copy of the database in its memory space.
>
> It fails with on-disk SQLite databases. SQLite can’t cope with this level 
> of concurrency. It timeouts while attempting to lock the database.
>
> It fails with PostgreSQL (and, I assume, other databases) because tests 
> collide, for instance when they attempt to load the same fixture.
>
> ** Next steps **
>
> At this point, the patch improves the common use case of running 
> `./runtests.py` locally to check a database-independent change, and little 
> else.
>
> Do you think it would be useful to include it in Django anyway? Do you 
> have concerns about the implementation? Charitably, I’ll say that “it 
> works”…
>
> Releasing it separately as a custom test runner may be more appropriate.
>
> What do you think?
>
> -- 
> 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/dc81ae00-80a9-466e-9f86-7b93968ea80a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Elimination of limitations of bulk_create in Django

[Elita Lobo]

>
> Hello Russell,
>
Thankyou for your response. I will try to fix a few easy bugs first 
as you suggested and then go for adding bulk_update or improving 
bulk_create.  
 I am interested in doing  a gsoc project under this organization 
if given the opportunity. I would like to start researching and working on 
either template engine optimization or replacing form media class. Could 
you please let me know whom I need to contact to discuss about the same? 
Also please let me know if I need to fix some bugs to prove my capability 
of doing this project before taking up the same. 
I have worked on several python projects which involved django while 
interning in some companies. I have also done a GSOC project last year 
related to Gnome Calculator.



 Thanks and Regards,
  Elita Lobo
 

On Friday, 6 February 2015 11:09:05 UTC+5:30, Elita Lobo wrote:
>
> Hello,
>
> I am a 3rd year student of NIT Durgapur , India as well as a Gnome 
> Developer . I have worked on many Python projects as well. I would like to 
> start contributing to django. 
> Django does not allow bulk_create of objects with many_to_many field nor 
> does it allow bulk update. Also it does not call save function which may be 
> a bit of a problem if the save method has been overriden. I would like to 
> work on finding a way around to eliminate these limitations.
>
> Kindly let me know if this is feasible and if I can submit a patch for the 
> same. 
> Also I would be grateful if you could point out a few bugs that could help 
> me get started with contributing to django.
>
>
> Thanking you,
>
>
> regards,
> Elita Lobo
>

-- 
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/13942bab-4225-4fcc-832c-68ae92788e61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding missing aggregate functions to contrib.postgres ?

[Michael Manfre]

It's reasonable to support backend specific aggregate functions. The
database backend API contains
BaseDatabaseOperations.check_expression_support for this exact reason. Feel
free to create the ticket.

Regards,
Michael Manfre

On Sat, Feb 7, 2015 at 9:00 AM, Andriy Sokolovskiy (coldmind) <
sokand...@yandex.ru> wrote:

> So, since django has contrib.postgres, maybe it would be reasonable to add
> postgres-specific aggregate functions to this module?
> If it is good idea, I'm gonna create ticket and implement this.
>
> --
> 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/2d3b2bd2-3bce-4e40-8383-ef5ca328bc26%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGdCwBtuSSi7x10-0pBLae1PRGA-ULmm6sxMAnzYqxdZLv7Kuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making the test suite run faster

[Aymeric Augustin]

On 7 févr. 2015, at 15:09, Fabio Caritas Barrionuevo da Luz  
wrote:

> Parallel is different than concurrent

Of course. I’m concerned with parallelism here because that’s what gives the 
performance improvement. Of course I have to make concurrency safe.

> did you come to look at the package "testtools", I think it implements 
> something similar to what you want to do

Yes, I started by attempting to use it. Unfortunately it relies an threads. 
That can’t work for Django’s tests, primarily because of `override_settings`.

-- 
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/C4E87CC7-1EF8-4A00-A79E-57D1756DD087%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Getting started : Contributing to Django

[Akshita Jha]

Hi,

I am an GSOC - 2015 Applicant. I am currently in my 3rd year B.Tech 
(Computer Science). I want to contribute to Django. It would be really 
helpful, if you could help me get started.

-- 
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/7f2a2186-6e67-40e0-8d5f-01194f7c259c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Getting started : Contributing to Django

[Tim Graham]

A good place to start is reading the contributing documentation: 
https://docs.djangoproject.com/en/dev/internals/contributing/

The next step is to find a ticket in the area you are interested in and 
then either:
1) review the existing patch if there is one,
2) improve an existing patch if it has comments for improvement but no one 
has responded to them, or
3) write a new patch if there isn't one.

On Saturday, February 7, 2015 at 1:57:24 PM UTC-5, Akshita Jha wrote:
>
> Hi,
>
> I am an GSOC - 2015 Applicant. I am currently in my 3rd year B.Tech 
> (Computer Science). I want to contribute to Django. It would be really 
> helpful, if you could help me get started.
>

-- 
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/b60519ea-d72c-4524-b276-ccc242aa0fb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding missing aggregate functions to contrib.postgres ?

[Andriy Sokolovskiy (coldmind)]

I opened a ticket for it.
https://code.djangoproject.com/ticket/24301

суббота, 7 февраля 2015 г., 18:51:34 UTC+2 пользователь Michael Manfre 
написал:
>
> It's reasonable to support backend specific aggregate functions. The 
> database backend API contains 
> BaseDatabaseOperations.check_expression_support for this exact reason. Feel 
> free to create the ticket.
>
> Regards,
> Michael Manfre
>
> On Sat, Feb 7, 2015 at 9:00 AM, Andriy Sokolovskiy (coldmind) <
> soka...@yandex.ru > wrote:
>
>> So, since django has contrib.postgres, maybe it would be reasonable to 
>> add postgres-specific aggregate functions to this module?
>> If it is good idea, I'm gonna create ticket and implement this.
>>
>> -- 
>> 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/2d3b2bd2-3bce-4e40-8383-ef5ca328bc26%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/048acd1a-4b02-4cb1-9cfe-7a62800f6f47%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Elimination of limitations of bulk_create in Django

[Tim Graham]

Please use this mailing list to communicate your ideas and questions 
regarding GSoC.

As I wrote in another thread, "Your odds of acceptance are greatly enhanced 
if you have a track record of producing good patches (and it will also help 
you write a better proposal, I think)."

On Saturday, February 7, 2015 at 9:43:36 AM UTC-5, Elita Lobo wrote:
>
> Hello Russell,
>>
> Thankyou for your response. I will try to fix a few easy bugs 
> first as you suggested and then go for adding bulk_update or improving 
> bulk_create.  
>  I am interested in doing  a gsoc project under this organization 
> if given the opportunity. I would like to start researching and working on 
> either template engine optimization or replacing form media class. Could 
> you please let me know whom I need to contact to discuss about the same? 
> Also please let me know if I need to fix some bugs to prove my capability 
> of doing this project before taking up the same. 
> I have worked on several python projects which involved django while 
> interning in some companies. I have also done a GSOC project last year 
> related to Gnome Calculator.
>
>
>
>  Thanks and Regards,
>   Elita Lobo
>  
>
> On Friday, 6 February 2015 11:09:05 UTC+5:30, Elita Lobo wrote:
>>
>> Hello,
>>
>> I am a 3rd year student of NIT Durgapur , India as well as a Gnome 
>> Developer . I have worked on many Python projects as well. I would like to 
>> start contributing to django. 
>> Django does not allow bulk_create of objects with many_to_many field nor 
>> does it allow bulk update. Also it does not call save function which may be 
>> a bit of a problem if the save method has been overriden. I would like to 
>> work on finding a way around to eliminate these limitations.
>>
>> Kindly let me know if this is feasible and if I can submit a patch for 
>> the same. 
>> Also I would be grateful if you could point out a few bugs that could 
>> help me get started with contributing to django.
>>
>>
>> Thanking you,
>>
>>
>> regards,
>> Elita Lobo
>>
>

-- 
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/f13b68ec-5e7f-41c0-9baa-3e5686be1598%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding missing aggregate functions to contrib.postgres ?

[Andriy Sokolovskiy (coldmind)]

OK, since ticket was market as accepted, should *all* aggregates functions 
from http://www.postgresql.org/docs/9.4/static/functions-aggregate.html be 
implemented ? I'm asking to prevent doing unnecessary work. 

воскресенье, 8 февраля 2015 г., 1:11:08 UTC+2 пользователь Andriy 
Sokolovskiy (coldmind) написал:
>
> I opened a ticket for it.
> https://code.djangoproject.com/ticket/24301
>
> суббота, 7 февраля 2015 г., 18:51:34 UTC+2 пользователь Michael Manfre 
> написал:
>>
>> It's reasonable to support backend specific aggregate functions. The 
>> database backend API contains 
>> BaseDatabaseOperations.check_expression_support for this exact reason. Feel 
>> free to create the ticket.
>>
>> Regards,
>> Michael Manfre
>>
>> On Sat, Feb 7, 2015 at 9:00 AM, Andriy Sokolovskiy (coldmind) <
>> soka...@yandex.ru> wrote:
>>
>>> So, since django has contrib.postgres, maybe it would be reasonable to 
>>> add postgres-specific aggregate functions to this module?
>>> If it is good idea, I'm gonna create ticket and implement this.
>>>
>>> -- 
>>> 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/2d3b2bd2-3bce-4e40-8383-ef5ca328bc26%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/38e08166-a475-4214-8055-e81eeb452c85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Loïc Bistuer]

That's what we've done in Django 1.7 for Form/ModelForm (#19617, #8620), and I 
completely agree that it should be possible to shadow fields from abstract 
models. The docs even suggest that this may be possible in the future; quoting 
the relevant section: "this [shadowing] is not permitted for attributes that 
are Field instances (at least, not at the moment)."

For consistency with forms - and because we've put a great deal of thinking 
into it - the implementation should be: you can shadow a field with another 
field, or you can remove a field using None as a sentinel value (see #22510 for 
more details).

I believe we have a safety net in the form of migrations, if you accidentally 
shadow a field, migrations will pick it up, so it's unlikely to go unnoticed.

I'd be quite happy to shepherd this patch.

Unit tests should cover those scenarios:

- An abstract model redefines or removes some fields from a parent abstract 
model.
- A concrete model redefines or removes some fields from a parent abstract 
model.
- Ensure that the standard MRO resolution applies when you do 
Concrete(AbstractA, AbstractB) with AbstractA redefining a field from AbstractB.

The last case may be tricky because if I remember well ModelBase iterates 
through the MRO in the wrong direction (i.e. bases should be iterated over in 
reverse).

We also need some tests to show how migrations behave.

-- 
Loïc

> On Feb 7, 2015, at 09:33, Marten Kenbeek  wrote:
> 
> Hi Russ,
> 
> I can see your point on accidentally overriding fields, though I'm not sure I 
> agree. In any other case, such as normal attributes and methods, there is no 
> safety net for overriding attributes either. Any model that would be affected 
> by this change would also raise an error on import without the patch, so 
> existing functional code won't be affected. On the other hand, a new 
> parameter for the field wouldn't be that much of a hassle to implement or 
> work with. I'd be interested to hear what others think about this.
> 
> There are more than a few questions on stack overflow that expect this 
> behaviour, even if the docs specifically mention that it won't work. If users 
> intuitively try to override fields in this manner, I think it would be 
> reasonable to allow this without any explicit arguments.
> 
> We can always restrict what you can override, at least as the default 
> behaviour, e.g. so that you can only use subclasses of the original field. 
> That would make code that depends on the abstract field less prone to bugs, 
> though subtle bugs can still happen if you e.g. override the max length of a 
> field. 
> 
> This was indeed just a proof-of-concept. That remark was meant more like "it 
> doesn't appear to break everything". 
> 
> Marten
> 
> Op vrijdag 6 februari 2015 23:48:55 UTC+1 schreef Marten Kenbeek:
> Hey,
> 
> While fiddling with django I noticed it would be trivial to add support for 
> shadowing fields from abstract base models. As abstract fields don't exist in 
> the database, you simply have to remove the check that reports name clashes 
> for abstract models, and no longer override the field. 
> 
> This would allow you to both override fields from third-party abstract models 
> (e.g. change the username length of AbstractUser), and to override fields of 
> common abstract models on a per-model basis. Previously you'd have to copy 
> the original abstract model just to change a single field, or alter the field 
> after the model definition. The first approach violates the DRY principle, 
> the second approach can introduce subtle bugs if the field is somehow used 
> before you changed it (rare, but it can happen). 
> 
> This patch adds the feature. It seems to work correctly when using the models 
> and creating/applying migrations, and passes the complete test suite. 
> 
> What do you guys think about this feature?
> 
> -- 
> 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/072149e1-c794-446d-957b-f5fc5df87096%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google