On 06/20/2016 06:57 PM, Tim Graham wrote: > I may have seen this idea in IRC but instead of a new > middleware_decorator function did you consider varying > decorator_from_middleware's behavior based on "if settings.MIDDLEWARE is > None" similar to what BaseHandler does? We could add a check in > decorator_from_middleware to raise an error if MIDDLEWARE is None and > the middleware doesn't seem to be the new-style.
I did think about that, but I think having the output of a function like this (which is usually called at import time) be non-deterministic depending on settings is problematic on several levels. At the most basic level, we usually try to avoid import-time settings access, to avoid an import causing a "DJANGO_SETTINGS_MODULE is not defined" error. But it also seems wrong for a decorator-generator to generate a completely different decorator based on settings. It's not uncommon that a third-party library might provide both a middleware and a decorator generated via decorator_from_middleware. Should the nature and behavior of that third-party decorator change fundamentally depending on whether it happens to be imported in a project that has (or hasn't) converted from MIDDLEWARE_CLASSES to MIDDLEWARE? What about a third-party old-style decorator from on old-style middleware, imported in a project using MIDDLEWARE? There's no reason that decorator can't work the same as it always has (the decorator itself doesn't have any dependency on which type of middleware your project uses), but under this proposal it would instead suddenly raise an error if you even try to import it. I think this approach is more problematic and less backwards-compatible (especially for third-party projects) than just introducing a new function and deprecating the old one. 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/57689D2E.3060600%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
