django 1.8 i18n behaviour change

[drakkan]

Hi,

I updated a project from 1.7 to 1.8 (tested both 1.8.0 and 1.8.1),

in my templates and python code I have string in my native language 
(italian),

so my po files look likes this:

1) locale en

msgid "original string in italian"
msgstr "english translated string"

2) locale it

msgid "original string in italian"
msgstr ""

now in settings I have:

LANGUAGE_CODE = 'en'

my browser is in italian so request.LANGUAGE_CODE is "it"

now in django 1.7 the fallback translation is taken from the it po file, in 
django 1.8+ en translation is used (probably since msgstr is empty and 
default LANGUAGE_CODE is "en")

do you consider this a bug?

thanks

-- 
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/4ccdde54-84a5-4b5a-a54d-9fba3bf2dc63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for help: building a docker/vagrant platform for running Django's test suite

[Pradeek J]

Any updates on this? I also want to take a crack at this and think its best 
to not duplicate efforts. Let me know how I can pitch in. 

On Wednesday, April 22, 2015 at 10:25:17 PM UTC+5:30, Kevin Glavin wrote:
>
> Thank you everyone for your interest. I spoke with Tim last night to start 
> piecing together the strategy. The gameplan on my end is to start a repo 
> that we can all work from and (in)formally define the high level strategy. 
> I'll enter any work items as issues on the github repo and share the link 
> once I have it configured. I will seed the repo with a container or two for 
> examples of what we're trying to accomplish and we can work together from 
> there.
>  
> —
> Sent from Mailbox  
>
>
> On Wed, Apr 22, 2015 at 12:46 PM, Micah Hausler  > wrote:
>
>> I've had a bit of experience with Docker and docker-compose (formerly 
>> fig), as I wrote the RST docs for docker-py, then reformatted them to MD. (
>> https://github.com/docker/docker-py/commits?author=micahhausler)
>>
>> I also wrote a container transformation library for converting 
>> docker-compose files to AWS ECS task.json files. 
>> https://github.com/ambitioninc/container-transform
>>
>> I think docker-compose could be a great fit for this, I'd be happy to 
>> help out.
>>
>> -Micah Hausler
>>  
>>
>> On Friday, April 17, 2015 at 7:27:17 PM UTC-4, Tim Graham wrote:
>>>
>>> In 2012, Julien Phalip started the djangocore-box project [1]: "A 
>>> virtual machine for running the Django core test suite with every supported 
>>> version of Python, every supported database backend and other 
>>> dependencies." Unfortunately, the project hasn't seen an update in a year 
>>> and a half, and I think we should take a different approach than the 
>>> current one of chef & vagrant to reflect today's best practices.
>>>
>>> We have some private Ansible playbooks for bootstrapping the Jenkins 
>>> continuous integration servers, and I believe these could be adapted for 
>>> use with Vagrant, Docker, or something else (let's discuss the best 
>>> solution; I'm not an expert) to create a successor to djangocore-box. I 
>>> would like a knowledgeable person who has time and interest to take the 
>>> lead on this and I could work with you based on my experience with Jenkins. 
>>> Feedback welcome!
>>>
>>> [1] https://github.com/jphalip/djangocore-box
>>>
>>   -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-developers/i-feBe7eDiA/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/3143f97f-70bc-48e8-86a6-aa5787a01f3c%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/49c2fc76-8a41-48b4-b577-ed5988208f56%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow deferral of ModelSignal callback invocation until after transaction commit

[Shai Berger]

Hi,

On Saturday 02 May 2015 07:20:00 Christopher Adams wrote:
> Hey guys,
> 
> Thanks for the great feedback and replies.
> 
> Generally agree with everyone that post-commit hooks shouldn't be strictly
> coupled to the signals framework philosophically speaking.
> 
> I disagree with Carl's premise that using `connection.on_commit` in your
> signal handler is simpler than adding `after_commit=True` as a kwarg. 

I think you're confusing "simple" with "easy", see 
http://www.infoq.com/presentations/Simple-Made-Easy

In particular, you are proposing to make one use-case easier, while making the 
semantics of the API much more complex (the most glaring  point: With your 
proposal, adding a keyword argument changes the signal handler invocation from 
synchronous to asynchronous, with everything that entails about error 
handling). I am -1 on that API, regardless of the "one way to do it" argument.

>  [using `connection.on_commit`] involves not only an extra import, but also
>  familiarity by developers with the notion of closure and callbacks. Despite
>  being a powerful feature of Python, this is not really as familiar a usage
>  pattern among developers

It is quite easy to hide the use of connection.on_commit, including the 
concepts of callback and closure, behind a small wrapper for handler 
registration. I'd hesitate before putting it in core, but you can prove me 
wrong by releasing it as a utility (or even a Django Snippet) and making it 
popular.

HTH,
Shai.

Re: Refactor year, month, day lookups?

[Michał Modzelewski]

I just recently needed to do date based aggregation at work, and I 
discovered that this functionality already exists in Django 1.8 after the 
query expression refactoring, but is undocumented. Your example can be 
written like this:

from django.db.models import Sum
from django.db.models.expressions import Date, DateTime
from django.utils.timezone import get_current_timezone

sales_per_month = Model.objects.annotate(month=Date('mydate', 'month'))\
.values('month')\
.annotate(sales=Sum('sale'))\
.order_by('month')
# or
sales_per_month = Model.objects.annotate(month=DateTime('mydate', 'month', 
get_current_timezone()))\
.values('month')\
.annotate(sales=Sum('sale'))\
.order_by('month')

I was thinking of writing some documentation for this so that users of 
Django 1.8 know they can use it and how. An obvious problem however, is 
that there is an error message in DateTime that refers specifically to it's 
usage in QuerySet.datetimes. Maybe this could be treated as a bug, and a 
patch for the error message could be backported?
This would also close https://code.djangoproject.com/ticket/10302

For 1.9 Date and DateTime could become importable from django.db.models 
like all the other expression classes.


On Wednesday, March 25, 2015 at 5:24:44 AM UTC+1, Josh Smeaton wrote:

> Hi,
>
> Firstly (and least importantly) opening a PR makes it a lot easier to 
> review code, especially when there are lots of commits. A [WIP] pull 
> request is common and useful. If you get a chance, you should open one with 
> this change.
>
> I think it's a good idea. So much so that I opened a ticket about a year 
> ago: https://code.djangoproject.com/ticket/22394. You'll note some 
> comments there about retaining the Year based behaviour as a `BETWEEN X and 
> Y` rather than `Extract(YEAR)`. Otherwise, I think the support is rather 
> positive. At a high level, your code looks fairly solid and I think would 
> be a useful addition.
>
> Another thing I would really like to see is transform based annotations. 
> I'm not 100% sure on whether .annotate(F('X__transform')) is supported or 
> not, but if it is, we'll get some really nice behaviour from the use of 
> transforms.
>
> Think:
>
> sales_per_month = Model.objects.annotate(month=F('mydate__month')).values(
> 'month').Aggregate(sales=Sum('sale'))
>
> If Transforms don't yet work with annotate, that'll probably be what I'd 
> like to implement next. But the first step is having transforms to work 
> with, where date based transforms are (to me) the most useful.
>
> Cheers,
>
> On Wednesday, 25 March 2015 13:39:39 UTC+11, Jon Dufresne wrote:
>>
>> Hi, 
>>
>> I have been spending some time learning and investigating the custom 
>> lookups feature that was newly introduced in 1.7 [0]. While 
>> investigating, I wanted to learn by example so I started looking 
>> through the Django code. In the end, I didn't find many examples. 
>> However, I did notice that there exists lookups for the year, month, 
>> day, (and more) value from a database date or datetime value [1]. 
>> These appear to be implemented as special case "builtin" lookups and 
>> not through the new lookup mechanism. Is there a specific reason for 
>> this or is it historical momentum? 
>>
>> I started investigating if these could be refactored to use the common 
>> code path and implemented using the new lookup mechanism. To my 
>> delight it was not very difficult and I now have all tests passing 
>> after refactoring these lookups. Right now, this lives in a branch of 
>> mine and not in a ticket or pull request. The WIP branch is located 
>> at:  
>>
>> Would this be something welcome as a ticket and pull request? While 
>> there is no outward change in functionality, I see it as a beneficial 
>> refactoring because with this change: 
>>
>> 1. The year, month, day, etc lookups are no longer treated as special 
>> cases, but instead use the common code path. 
>> 2. There now exists complete and useful examples of registering new 
>> lookups in the Django code itself. This might help others build more 
>> lookups. 
>> 3. The lookups are now limited to the correct Field types where as 
>> previously this was not true. I demonstrate this with a unit test. 
>>
>> If this looks like it could be a welcome change I will can go forward 
>> with a typical ticket and pull request. 
>>
>> Cheers, 
>> Jon 
>>
>> [0] https://docs.djangoproject.com/en/dev/howto/custom-lookups/ 
>> [1] https://docs.djangoproject.com/en/dev/ref/models/querysets/#year 
>>
>

-- 
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

Re: Request for help: building a docker/vagrant platform for running Django's test suite

[Kevin Glavin]

Hi all,




Working on getting the repo baselined and pushed to github this weekend. Had a 
hellacious past week. Will provide the URL ASAP.



—
Sent from Mailbox

On Sat, May 2, 2015 at 6:15 AM, Pradeek J  wrote:

> Any updates on this? I also want to take a crack at this and think its best 
> to not duplicate efforts. Let me know how I can pitch in. 
> On Wednesday, April 22, 2015 at 10:25:17 PM UTC+5:30, Kevin Glavin wrote:
>>
>> Thank you everyone for your interest. I spoke with Tim last night to start 
>> piecing together the strategy. The gameplan on my end is to start a repo 
>> that we can all work from and (in)formally define the high level strategy. 
>> I'll enter any work items as issues on the github repo and share the link 
>> once I have it configured. I will seed the repo with a container or two for 
>> examples of what we're trying to accomplish and we can work together from 
>> there.
>>  
>> —
>> Sent from Mailbox  
>>
>>
>> On Wed, Apr 22, 2015 at 12:46 PM, Micah Hausler > > wrote:
>>
>>> I've had a bit of experience with Docker and docker-compose (formerly 
>>> fig), as I wrote the RST docs for docker-py, then reformatted them to MD. (
>>> https://github.com/docker/docker-py/commits?author=micahhausler)
>>>
>>> I also wrote a container transformation library for converting 
>>> docker-compose files to AWS ECS task.json files. 
>>> https://github.com/ambitioninc/container-transform
>>>
>>> I think docker-compose could be a great fit for this, I'd be happy to 
>>> help out.
>>>
>>> -Micah Hausler
>>>  
>>>
>>> On Friday, April 17, 2015 at 7:27:17 PM UTC-4, Tim Graham wrote:

 In 2012, Julien Phalip started the djangocore-box project [1]: "A 
 virtual machine for running the Django core test suite with every 
 supported 
 version of Python, every supported database backend and other 
 dependencies." Unfortunately, the project hasn't seen an update in a year 
 and a half, and I think we should take a different approach than the 
 current one of chef & vagrant to reflect today's best practices.

 We have some private Ansible playbooks for bootstrapping the Jenkins 
 continuous integration servers, and I believe these could be adapted for 
 use with Vagrant, Docker, or something else (let's discuss the best 
 solution; I'm not an expert) to create a successor to djangocore-box. I 
 would like a knowledgeable person who has time and interest to take the 
 lead on this and I could work with you based on my experience with 
 Jenkins. 
 Feedback welcome!

 [1] https://github.com/jphalip/djangocore-box

>>>   -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/django-developers/i-feBe7eDiA/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, 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/3143f97f-70bc-48e8-86a6-aa5787a01f3c%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/django-developers/i-feBe7eDiA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/49c2fc76-8a41-48b4-b577-ed5988208f56%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/1430589860909.781c4edb%40Nodemailer.
For more options, visit https://groups.google.com/d/optout.

Re: Removing global database converters and adapters for datetimes

[Aymeric Augustin]

On 13 avr. 2015, at 20:13, Aymeric Augustin 
 wrote:

> Replacing adapters is a bit more tricky. Removing them causes the two
> regression tests for #17755 to fail. I haven't determined how I can process
> parameters passed to QuerySet.raw(), but since that's part of the ORM, I'm
> optimistic.

Well… I was optimistic :-) I need help.

I’m looking for a way to fix https://code.djangoproject.com/ticket/17755
without registering adapters at the level of the DB-API module (sqlite3,
MySQLdb, etc.)

In a regular QuerySet / Query, a parameter is tied to a field (or equivalent,
like an expression, which has an output field). The field's get_db_prep_value
method is used to transform the parameter to an appropriate value for the
DB-API module. In general, datetime objects are handled by a DateTimeField,
whose get_db_prep_value method calls connection.ops.value_to_db_datetime, and
everything is fine.

Unfortunately, a RawQuerySet / RawQuery cannot use the same logic because its
parameters aren't tied to fields. For lack of a better idea, I'm proposing to
add a best-effort conversion function to BaseDatabaseOperations:

def value_to_db(self, value):
"""
Transforms a value to something compatible with the backend driver.

This method only depends on the type of the value. It's designed for
cases where the target type isn't known. As a consequence it may not
work perfectly in all circumstances.
"""
if isinstance(value, datetime.datetime):   # must be before date
return self.value_to_db_datetime(value)
elif isinstance(value, datetime.date):
return self.value_to_db_date(value)
elif isinstance(value, datetime.time):
return self.value_to_db_time(value)
elif isinstance(value, decimal.Decimal):
return self.value_to_db_decimal(value)
else:
return value

Then I will invoke this method on all parameters, most likely in
RawQuery._execute_query. This is the last step in the call chain:

Model.objects.raw
-> RawQuerySet.__iter__
-> RawQuery.__iter__
-> RawQuery._execute_query
-> cursor.execute

Does that make sense?

I know that I'm duplicating the functionality of database adapters, but I
don't have much choice if I don't want to touch the default global adapters.

-- 
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/D6217D53-6933-43AB-93D9-8B735F1C5FA8%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Tim Graham]

I made a few edits based on recent feedback. I'll publicize it via the 
djangoproject.com some time next week.

On Wednesday, April 29, 2015 at 1:59:20 AM UTC-4, Markus Holtermann wrote:
>
> It's an amazing idea. Thanks for putting it up, Aymeric and Tim!
>
> Can we add a question regarding usage of test frameworks (i.e., unittest2, 
> py.test, nose) similar to "Which popular third-party apps do you rely on?" 
> For example "Which test frameworks do you use?" - "unittest2, py.test, 
> nose, other". That would allow us to see if we should / can include 
> features in django.test that may require a specific framework without 
> excluding too many people of our community.
>
> /Markus
>
> On Monday, April 27, 2015 at 9:59:24 PM UTC+2, Thorsten Sanders wrote:
>>
>>  I wrote in that thread too why I dont like such fast releases and at 
>> least someone else asked too to give more options on that one question, on 
>> the developer mailing list its kinda only some people who are writing not 
>> reflecting all the developers such an survey maybe reach more of them and 
>> then the answer about such an important question shouldnt be reduced to 3 
>> little options a handfull people decided on, that wouldnt reflect what 
>> people really want if they cant choose an real answer.
>>
>> Am 27.04.2015 02:46, schrieb Tim Graham:
>>  
>> The idea of the release schedule question is to form consensus on the 
>> options that have already been proposed in the "1.9 release planning 
>> "
>>  
>> thread. If you have a different idea, please propose it there.
>>
>> On Sunday, April 26, 2015 at 6:53:14 AM UTC-4, Thorsten Sanders wrote: 
>>>
>>>  I like the idea of an survey, but find the release question with only 
>>> 3 options quite limited, how about to allow there to put own numbers 
>>> instead of giving fixed answers or at least an other field?
>>>
>>> Am 25.04.2015 14:29, schrieb Tim Graham:
>>>  
>>> Aymeric and I put together a draft:
>>>
>>>
>>> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform
>>>
>>> All questions are optional so you can just click through it to view the 
>>> questions. We'll probably clear any responses before its finalized anyway.
>>>
>>> Let us know if you think we should make any additions or changes.
>>>
>>> On Wednesday, April 22, 2015 at 4:03:44 AM UTC-4, Federico Capoano 
>>> wrote: 

 Great idea. 
 The questions look good enough to me.

  I love django-apps or libraries shipped in python packages. One of 
 the reason I love Django is the fact that it didn't frenetically add stuff 
 to the framework just because it's cool.
 The good thing of python packages is that you can get some data from 
 pypi (downloads) and github (clones). But we can't do that with contrib 
 apps unfortunately.

  Federico


 On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham wrote: 
>
> I had an idea to conduct a survey to get a sense of how developers are 
> using Django. I first had the idea when the question of maintenance of 
> the 
> Oracle GIS backend came up. We really have no idea whether or not anyone 
> is 
> actually using that backend, and it would be helpful to know so we are 
> not 
> wasting resources on unused features. Also there's the question of how 
> often to release Django. I think it would be nice to make that decision 
> based on some data from the community.
>
> Is anyone is interested in coordinating such a survey (collating 
> questions, preparing the online survey, etc.).
>
> Some question ideas to get started:
>
> Which database backend(s) do you use?
> [ ] Checkbox for each one
>
> Which contrib apps do you use?
> [ ] Checkbox for each one
>
> How often would you like to see new major version of Django released?
> [ ] List some options, probably between 6 and 9 months.
>
> Describe which version of Django you use (check all the apply):
> [ ] I only use long-term support releases.
> [ ] I upgrade to the latest stable version as quickly as possible.
> [ ] I run off of master.
> [ ] I upgrade Django when the version I am using is nearing the end of 
> its support (or after).
> [ ] I don't bother upgrading Django, even if it becomes unsupported.
>  
   -- 
>>> 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/f14071d1-c570

Fellow Report - May 1, 2015

[Tim Graham]

In addition to these tasks, rolled the 1.8.1 and 1.7.8 bug fix releases 
yesterday.


Report for week ending May 1, 2015:

Triaged

---

https://code.djangoproject.com/ticket/24708 - 
forms.GenericIPAddressField.to_python behaves differently to other 
CharField subclasses. (accepted)

https://code.djangoproject.com/ticket/24710 - Replace BaseForm.errors 
property with get_errors method (won’t fix)

https://code.djangoproject.com/ticket/24706 - ModelForm._post_clean assumes 
that setting attributes onto an instance cannot raise ValidationError 
(accepted)

https://code.djangoproject.com/ticket/24709 - ArrayField doesn't support 
.update() and F() objects (accepted)

https://code.djangoproject.com/ticket/24711 - Allow flush management 
command to drop tables and re-run migrations (accepted)

https://code.djangoproject.com/ticket/24720 - using middleware.common to 
append slashes causes extra overhead to all requests that do not end in a 
slash (accepted)

https://code.djangoproject.com/ticket/24725 - "ProgrammingError: relation 
does not exist" when renaming many-to-many target model (accepted)

https://code.djangoproject.com/ticket/24727 - ClearableFileInput masks 
useful exceptions in is_initial() (accepted)

https://code.djangoproject.com/ticket/24726 - ArrayField with 
IntegerRangeField as base field generates invalid SQL on Insert operations 
(accepted)

https://code.djangoproject.com/ticket/24718 - Inconsistent Behavior by 
Admin when Creating vs Deleting Objects (won’t fix)

https://code.djangoproject.com/ticket/24728 - feedgenerator classes still 
use "mime_type" instead of "content_type" (accepted)

https://code.djangoproject.com/ticket/24731 - ManyToMany model clean 
validation of related fields (needsinfo)

Authored



https://github.com/django/django/commit/3b133ffb8bdf1e0e4c3f2c3af8a62376da643350
 
- Fixed template_tests failure on Windows. 

https://github.com/django/django/pull/4592 - Fixed #24676 -- Fixed help 
text positioning in ``contrib.admin`` filter_* widgets.

https://github.com/django/django/pull/4578 - Fixed #24724 -- Fixed GIS 
initialization crash on Windows.

Reviewed/committed

--

https://github.com/django/django/pull/4570 - Fixed #24714 -- Used more 
specific assertions than assertEqual in tests.

https://github.com/django/django/pull/4565 - Fixed #13008 -- Added more 
Cache-Control headers to never_cache() decorator.

https://github.com/django/django/pull/4576 - Fixed #24717 -- Fixed 
model_regress test failure on RHEL6 SCL

https://github.com/django/django/pull/4580 - Added translation.override() 
context manager to docs.

https://github.com/django/django/pull/4582 - Fixed #24729 -- Removed test 
db flush when using --keepdb.

https://github.com/django/django/pull/4532 - Fixed #23271 -- Fixed 
makemessages crash/test failure for some locales.

https://github.com/django/django/pull/4559 - Fixed #23387 -- Keep "Save as 
new" button after validation errors

https://github.com/django/django/pull/4550 - Fixed #24696 -- Made 
CSRF_COOKIE computation lazy.

Reviews of core dev work



https://github.com/django/django/pull/4556 - Fixed #24119, #24120 -- 
Formalized debug integration for template backends
https://github.com/django/django/pull/4584 - Fixed #24725 -- Allowed 
renaming of target models in ManyToMany relations
https://github.com/django/django/pull/4590 - Fixed #24733 -- Passed the 
triggering exception to 40x error handlers

-- 
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/6db2b800-f70a-44e6-bfed-24056caa8a1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.