Thanks, I have what I hope is a minimally mergable patch here: 
https://github.com/django/django/pull/6501

As noted on the PR, there a more things that should be before the 1.10 
feature freeze but I'm hoping I can ticket them out and get some help from 
the community after merging this first step so that I can continue spending 
most of my time reviewing patches.

On Friday, May 6, 2016 at 7:59:38 PM UTC-4, Carl Meyer wrote:
>
> I agree with Simon on both counts. We do usually continue to test 
> deprecated code paths until they are removed, but I also think the 
> duplication in cases of tests overriding MIDDLEWARE_CLASSES might not be 
> necessary in _all_ cases; I think some discretion could be used 
> depending on to what extent the middleware is incidental to the tests vs 
> the direct subject of the test. But it might be simpler to just do them 
> all than to make that determination. 
>
> Carl 
>
> On 05/04/2016 08:57 PM, charettes wrote: 
> > Hi Tim, 
> > 
> > I think we should favor displaying a message in accordance with the 
> > setting the user is using as it will make the transition less confusing. 
> > In the case of the documented check message I think using the form 
> > "MIDDLEWARE/MIDDLEWARE_CLASSES" would make it easier to read then 
> > mentioning the two possible variants. We already alter the document 
> > messages anyway to account for their dynamic nature. 
> > 
> > In the case of the tests I believe both code path should continue to be 
> > tested. From the top of my head I can't think of an alternative to 
> > subclasses using @override_settings. I suggest we make the *legacy* 
> > tests class extend the MIDDLEWARE using test class and not the other way 
> > around as it will make the MIDDLEWARE_CLASSES code removal clearer. 
> > 
> > Simon 
> > 
> > Le mercredi 4 mai 2016 19:59:05 UTC-4, Tim Graham a écrit : 
> > 
> >     I've been working on this and wanted to raise a couple points for 
> >     discussion. 
> > 
> >     How should we treat error messages in place like system checks where 
> >     we have phrases like "Edit your MIDDLEWARE_CLASSES" ... of course 
> >     the check can easily check both MIDDLEWARE and MIDDLEWARE_CLASSES 
> >     without much effort but should we make the error message "smart" and 
> >     display the version of the setting that the user is using? 
> >     Alternatively, we could always reference MIDDLEWARE (the 
> >     non-deprecated version) or use some variation like 
> >     "MIDDLEWARE(_CLASSES)" or "MIDDLEWARE/MIDDLEWARE_CLASSES" until the 
> >     deprecation period ends. 
> > 
> >     Another point for discussion is whether we need to duplicate a lot 
> >     of tests so we test that the middleware continue to work with both 
> >     the old-style MIDDLEWARE_CLASSES and the new style MIDDLEWARE 
> >     response handling. I guess a subclass of anything that uses 
> >     @override_settings(MIDDLEWARE=...) that uses 
> >     @override_settings(MIDDLEWARE_CLASSES=...) might work. Just putting 
> >     it out there in case anyone has a better idea. 
> > 
> >     On Monday, January 18, 2016 at 9:20:03 PM UTC-5, Carl Meyer wrote: 
> > 
> >         I've updated DEP 5 with a new round of clarifications and tweaks 
> >         based on the most recent feedback: 
> >         https://github.com/django/deps/compare/62b0...master 
> >         <https://github.com/django/deps/compare/62b0...master> 
> > 
> >         Carl 
> > 
> > -- 
> > 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 <javascript:> 
> > <mailto:django-developers+unsubscr...@googlegroups.com <javascript:>>. 
> > To post to this group, send email to django-d...@googlegroups.com 
> <javascript:> 
> > <mailto:django-d...@googlegroups.com <javascript:>>. 
> > 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/eb1cf3f4-c021-40f6-be65-35427b2bf5c5%40googlegroups.com
>  
> > <
> https://groups.google.com/d/msgid/django-developers/eb1cf3f4-c021-40f6-be65-35427b2bf5c5%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/04f2e0f0-aa41-4a24-abea-85d8c292bcc5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to