Re: re-thinking middleware

2016-01-11 Thread Shai Berger 
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 ignored.
> 
> I suggest that, instead, this fails loudly if both ``MIDDLEWARE`` and
> ``MIDDLEWARE_CLASSES`` are set.
> This would prevent projects from keeping the two versions around and
> having to remember which one is currently in use.
> 

If the failure is too loud, it makes it hard to use the same settings file for 
testing with multiple versions of Django -- a practice used by Django itself, 
and I think also by some reusable apps. We've run into this issue with the 
change of the database test settings.

Shai.

Re: re-thinking middleware

2016-01-11 Thread Carl Meyer 
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 that, instead, this fails loudly if both ``MIDDLEWARE`` and
> ``MIDDLEWARE_CLASSES`` are set.
> This would prevent projects from keeping the two versions around and
> having to remember which one is currently in use.

Yes, that's a good idea. I think I had vaguely in mind that this wasn't
possible because the global default for MIDDLEWARE_CLASSES is non-empty,
but I guess we can still check to see whether the actual value != the
global default.

> Beyond that, I love the overall design of this upgrade :)

Great!

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-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/5693EE27.5000209%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: 1.8 shipping invalid .py files in the startapp template

2016-01-11 Thread Tim Graham 
Seems reasonable to me.

On Monday, January 11, 2016 at 10:24:18 AM UTC-5, Carl Johnson wrote:
>
> I think the template files should be shipped out as .py-tpl, since that's 
> their type (a Python template), and the resulting final files should just 
> have the extension renamed. Having two extension is just confusing and 
> leads to questions like this one about other kinds of templates.
>

-- 
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/98f2a5a1-53bf-488d-847c-98407e16312d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.8 shipping invalid .py files in the startapp template

2016-01-11 Thread Carl Johnson 
I think the template files should be shipped out as .py-tpl, since that's 
their type (a Python template), and the resulting final files should just 
have the extension renamed. Having two extension is just confusing and 
leads to questions like this one about other kinds of templates.

-- 
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/ed0b6b0e-4ff5-47b9-a887-64ff34dcd648%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: re-thinking middleware

2016-01-11 Thread Tim Graham 
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 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 people in the thread) below: 
> > 
> > On 01/08/2016 09:01 AM, Florian Apolloner wrote: 
> > > 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/ 
> > 
> > Yes, the latter is what Pyramid does and what I had in mind; in fact, 
> > its performance benefits are one of the justifications given in the 
> > DEP for why to use the factory approach rather than simple functions. 
> > I don't think "changing middlewares per request" is a use case that's 
> > worth the performance implications (and it's not a use case we 
> > currently support anyway). 
> > 
> > Thanks for the super-quick turnaround on implementation! 
> > 
> > On 01/08/2016 10:35 AM, Aymeric Augustin wrote: 
> > > 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”, I would 
> > > require raising MiddlewareNotUsed explicitly to disable a 
> > > middleware. A middleware factory that returns None would cause an 
> > > ImproperlyConfigured exception. Otherwise middleware could be 
> > > skipped by mistake, if the developer forgets to return the 
> > > middleware from the factory. This is especially a concern for 
> > > production-only middleware that developers can’t run locally. 
> > [snip] 
> > 
> > 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 given, which has the same effect of "skipping yourself." That 
> > falls out naturally from the concept, so I don't see any reason to 
> > disallow it, but we don't need to mention it in the docs if we want to 
> > stick to "one way to do it." 
> > 
> > On 01/08/2016 04:51 AM, Markus Holtermann wrote: 
> > > I would, however, include the exception handling in the examples 
> > > provided in section "Specification" as that is an integral part of 
> > > middlewares, too. 
> > 
> > Good idea, I've made that change in the commit linked above. 
> > 
> > > 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. 
> > https://github.com/rack/rack/issues/332, where a number of people 
> > fervently argue that "middleware" is a "mass noun" along the lines of 
> > e.g. "furniture", and that it is even incorrect to say "a middleware" 
> > (much like you would never say "a furniture"); instead we should 
> > always say "a middleware component." 
> > 
> > I think those people are fighting a lost battle; the usage of 
> > "middleware" as singular is already well established in the Python 
> > world, even outside Django; people frequently talk about "a WSGI 
> > middleware." 
> > 
> > That said, my ear still prefers "middleware" as both the singular and 
> > the plural (there are such words in English) and dislikes 
> > "middlewares." So I'd prefer to stick with MIDDLEWARE and haven't 
> > changed it in the spec. But if most people think MIDDLEWARES is 
> > better, I won't stand in the way. 
> > 
> > We could also go with something like MIDDLEWARE_FACTORIES or 
> > MIDDLEWARE_PIPELINE and avoid the issue altogether :-) 
> > 
> > Carl 
> > 
>
>
>
> 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 ignored. 
>
> I suggest that, instead, this fails loudly if both ``MIDDLEWARE`` and 
> ``MIDDLEWARE_CLASSES`` are set. 
> This would prevent projects from keeping the two versions around and 
> having to remember which one is currently in use. 
>
>
> Beyond that, I love the overall design of this upgrade :) 
>
> -- 
> Raphaël 
>
>

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