Hi Shai, On 06/20/2016 11:07 PM, Shai Berger wrote: > Well, we can change decorator_from_middleware to introspect the middleware > itself and decide accordingly: > > -- if it does not have process_request or process_response as callable > attributes, and it is callable itself, it is a new-style middleware
"Does not have process_request and process_response as callable attributes" isn't reliable -- there's nothing preventing a new-style middleware from having such methods and calling them from `__call__` (in fact any middleware converted using MiddlewareMixin will fit this description). > -- if it does, we can define a new attribute '_dep5' (or something) whose > presence will indicate a dep5-compatible middleware. This attribute can be > defined on the transition mixin, so that people who use it for transition > don't > have to care > > -- if it has callable process_request/process_response and doesn't have _dep5 > then it is an old-style middleware > > Note that decorator_from_middleware already used to instantiate the > middleware > class anyway, so the check can be applied to a middleware object, not to a > middleware factory. > > The whole introspection behavior, including the _dep5 attribute and the code > that checks for it, can be dropped when old-style middleware is finally > dropped. If someone uses _dep5 manually, it will do them no harm later. We can indeed introspect to try to auto-detect. It's a bit more complex due to the different `__init__` signature as well, and it would fail in case someone defined __call__ on an old-style middleware for some reason, but I've already written the code for this in https://github.com/django/django/pull/6765 The main reason I abandoned auto-detection for this second attempt is that the behavior of these new-style view decorators is different enough that I'd like to provide better flexibility for third-party projects. Imagine a third-party project that currently provides both a middleware and a view decorator, created by decorator_from_middleware. Now they are adding Django 1.10 compatibility. If we auto-detect, and they inherit their middleware from the transition mixin so it's cross-compatible, decorator_from_middleware will suddenly detect it as new-style, leaving them no way to continue to provide their old decorator with fully backwards-compatible behavior. Basically, I think middleware_decorator does something that's fundamentally different enough from decorator_from_middleware that it is clearer to make it a separate function and let people make explicit choices about which one they are using. 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/57696C0F.5050804%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
