Re: re-thinking middleware

The technical board has approved DEP 5, and since the patch [1] is also ready to go, I moved it straight to Final state. Thanks to everyone who contributed to the discussion, and especially to Florian and Tim for the patch. Carl [1] https://github.com/django/django/pull/6501 -- You

Re: re-thinking middleware

On 05/10/2016 03:37 PM, Carl Meyer wrote: > I've > updated the DEP with a couple minor changes to reflect the latest > learnings from the implementation; you can see the latest changes at > https://github.com/django/deps/compare/763530e1a9...master Better version of this link (to exclude more

Re: re-thinking middleware

On 05/07/2016 08:27 AM, Tim Graham wrote: > Thanks, I have what I hope is a minimally mergable patch here: > https://github.com/django/django/pull/6501 Thanks Tim (and Florian for all the previous work on this patch). I've updated the DEP with a couple minor changes to reflect the latest

Re: re-thinking middleware

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

Re: re-thinking middleware

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

Re: re-thinking middleware

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

Re: re-thinking middleware

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

Re: re-thinking middleware

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 Carl -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)"

Re: re-thinking middleware

On 01/10/2016 04:54 PM, Raphaël Barrois wrote: > I've got only one minor suggestion to the "backwards compatibility" > section of the DEP. > >> It currently states that "If the ``MIDDLEWARE`` setting is provided >> [...], the old ``MIDDLEWARE_CLASSES`` setting will be ignored. > > I suggest

Re: re-thinking middleware

On 01/11/2016 04:52 PM, Shai Berger wrote: > On Monday 11 January 2016 01:54:58 Raphaël Barrois wrote: >> I've got only one minor suggestion to the "backwards compatibility" >> section of the DEP. >> >>> It currently states that "If the ``MIDDLEWARE`` setting is provided >>> [...], the old

Re: re-thinking middleware

Hi Mat, On 01/12/2016 04:23 PM, Mat Clayton wrote: > +1 as well, this is really great work, on both patches! > > Modifying the middleware stack mid request would be very useful for us. > > We currently run 3 copies of the same code, with essentially different > urls.py and middlewares loaded,

Re: re-thinking middleware

Hey guys, +1 as well, this is really great work, on both patches! Modifying the middleware stack mid request would be very useful for us. We currently run 3 copies of the same code, with essentially different urls.py and middlewares loaded, each one is used to run a variation of the site, for

Re: re-thinking middleware

On Monday 11 January 2016 01:54:58 Raphaël Barrois wrote: > > Hi, > > I've got only one minor suggestion to the "backwards compatibility" > section of the DEP. > > > It currently states that "If the ``MIDDLEWARE`` setting is provided > > [...], the old ``MIDDLEWARE_CLASSES`` setting will be

Re: re-thinking middleware

On 01/10/2016 04:54 PM, Raphaël Barrois wrote: > I've got only one minor suggestion to the "backwards compatibility" > section of the DEP. > >> It currently states that "If the ``MIDDLEWARE`` setting is provided >> [...], the old ``MIDDLEWARE_CLASSES`` setting will be ignored. > > I suggest

Re: re-thinking middleware

That warning sounds like a good idea. We have a similar warning if both the old and new style template settings are defined: https://github.com/django/django/commit/24620d71f2116da31abe6c9391f7bc807ac23c0b On Sunday, January 10, 2016 at 6:57:09 PM UTC-5, Raphaël Barrois wrote: > > On Fri, 8 Jan

Re: re-thinking middleware

On Fri, 8 Jan 2016 11:38:04 -0700 Carl Meyer wrote: > Thanks everyone for the reviews. I've pushed a new commit addressing > most of the issues raised: > https://github.com/django/deps/commit/62b0ee351727cb0e7ef41ba6dd2f3f7280a219de > > More comments and replies (to various

Re: re-thinking middleware

On 01/08/2016 11:38 AM, Carl Meyer wrote: > On 01/08/2016 04:51 AM, Markus Holtermann wrote: >> Nitpicking, I would also name the settings variable MIDDLEWARES >> (i.e.plural) as it is a list of middlewares, not just one. > > Well, this is a matter of some debate :-) See e.g. >

Re: re-thinking middleware

> On Jan 8, 2016, at 12:53 PM, Carl Meyer wrote: > > On 01/08/2016 11:48 AM, Ryan Hiebert wrote: >> >> While class-based middleware factories couldn't just do the same thing >> in the __init__ method, they could do that in a __new__ method instead, >> and then we could make

Re: re-thinking middleware

Hi Ryan, On 01/08/2016 11:48 AM, Ryan Hiebert wrote: > I hadn't considered the option of just returning ``get_response``. > I really like it, because it avoids both raising an exception and > importing a common symbol. > > While class-based middleware factories couldn't just do the same thing >

Re: re-thinking middleware

> On Jan 8, 2016, at 12:38 PM, Carl Meyer wrote: > > Yes, you and Ryan are absolutely right, allowing `None` was a mistake > and I've removed it from the spec. For function-based middleware, > there's also the option to simply return the ``get_response`` callable > you were

Re: re-thinking middleware

Thanks everyone for the reviews. I've pushed a new commit addressing most of the issues raised: https://github.com/django/deps/commit/62b0ee351727cb0e7ef41ba6dd2f3f7280a219de More comments and replies (to various people in the thread) below: On 01/08/2016 09:01 AM, Florian Apolloner wrote: > PR1

Re: re-thinking middleware

> On Jan 8, 2016, at 11:57 AM, Ryan Hiebert wrote: > >> On Jan 8, 2016, at 11:35 AM, Aymeric Augustin >> wrote: >> >> In the spirit of “there should be only one way to do it”, I would require >> raising MiddlewareNotUsed explicitly

Re: re-thinking middleware

> On Jan 8, 2016, at 11:35 AM, Aymeric Augustin > wrote: > > +1 > > Great work. > > The only (and minor) concern I have is about allowing function-based > middleware factories to return None. > > In the spirit of “there should be only one way to do it”,

Re: re-thinking middleware

elcome! > > ==== > DEP 0005: Re-thinking middleware > > > :DEP: 0005 > :Author: Carl Meyer > :Implementation Team: Florian Apolloner > :Shepherd: Carl Meyer > :Status: Draft > :Type: Feature > :Cre

Re: re-thinking middleware

Hi Curtis, On 01/08/2016 04:31 AM, Curtis Maloney wrote: > In general, I love it. Great! > It's MUCH simpler for people to write and comprehend... requires no > classes [but IMHO the callable class is "cleaner"] and allows for > configurable middlewares easily... > > I do wonder, though... how

Re: re-thinking middleware

PR1 (allows changing the middlewares during the middleware run): https://github.com/django/django/pull/5591 PR2 (static middleware chain, seems simpler and probably the way to go): https://github.com/django/django/pull/5949/ On Friday, January 8, 2016 at 4:55:08 PM UTC+1, Florian Apolloner

Re: re-thinking middleware

Haha, I was so focused on my previous approach that I forgot, that I could just chain them during setup (thanks knbk). So the question remaining now: Do we want to be able to change middlewares per request or not :D I guess I'll submit a second PR with the non-request usage. On Friday, January

Re: re-thinking middleware

I've gone ahead and pushed a new commit to match the spec (not tested yet, but hey :D). On Friday, January 8, 2016 at 3:29:01 PM UTC+1, Florian Apolloner wrote: > > Mhm, > > I currently see no easy way to give *get_response* access to the list of > middlewares like done in >

Re: re-thinking middleware

Mhm, I currently see no easy way to give *get_response* access to the list of middlewares like done in https://github.com/django/django/pull/5591/files#diff-dbd7d9159676b15fc9a096b0adb919e9R122 and following lines. The reason is that providing *get_response* at setup/init time means it has

Re: re-thinking middleware

On Friday, January 8, 2016 at 12:51:25 PM UTC+1, Markus Holtermann wrote: > > Nitpicking, I would also name the settings variable MIDDLEWARES (i.e. > plural) as it is a list of middlewares, not just one. > Yes, my thought too. On January 8, 2016 10:31:49 PM GMT+11:00, Curtis Maloney <

Re: re-thinking middleware

Thank you Florian and Carl for continuing the work on that topic. I like both the DEP as well as the example. I would, however, include the exception handling in the examples provided in section "Specification" as that is an integral part of middlewares, too. Nitpicking, I would also name the

Re: re-thinking middleware

jango/deps/blob/master/draft/0005-rethinking-middleware.rst and I'm also pasting the full text below, to ease in-line commenting via email. Comments welcome! DEP 0005: Re-thinking middleware :DEP: 0005 :Author: Carl Meyer :Impl

Re: re-thinking middleware

Sent from my iPhone > On Jan 7, 2016, at 20:50, Carl Meyer wrote: > > Hi all, > > Back at the Django Under the Hood sprints in November, Florian and I > started batting around some ideas for fixing some of the problems with > the existing middleware abstraction. Florian put

re-thinking middleware

email. Comments welcome! DEP 0005: Re-thinking middleware :DEP: 0005 :Author: Carl Meyer :Implementation Team: Florian Apolloner :Shepherd: Carl Meyer :Status: Draft :Type: Feature :Created: 2016-01-07 :Last-Modified: 2016-01-07