> it's backwards incompatible and so we cannot make the change. Any URL with a > “reason” URL parameter would no longer be resolvable.
I think if we decided this feature was sufficiently worthwhile, we could find a way to overcome the backward compatibility problem (a deprecation cycle, with perhaps a temporary setting or a new function with the extra functionality). That said, I'm not clear on what the potential benefits of this change actually are, and I suspect they don't reach the high barrier to justify the extra hassle here. Sent with [Proton Mail](https://proton.me/) secure email. ------- Original Message ------- On Monday, August 7th, 2023 at 14:09, 'Adam Johnson' via Django developers (Contributions to Django itself) <django-developers@googlegroups.com> wrote: > This sounds reasonable, but unfortunately, it's backwards incompatible and so > we cannot make the change. Any URL with a “reason” URL parameter would no > longer be resolvable. > > You can make a project-specific shortcut function that allows providing the > reason parameter. Since it’s two lines long, it’s not a huge burden to add. > > On Mon, Aug 7, 2023 at 10:48 AM Skrattoune <skratto...@gmail.com> wrote: > >> Hi, >> >> I've recently discovered the possibility to add a `reason` to a redirect. >> >> It's extremely useful for testing or debugging when a redirect to a same >> page can have different causes. >> >> I'm proposing to add this functionality to `django.shortcuts.redirect` : >> >> def redirect(to, *args, reason=None, permanent=False, **kwargs): >> """ >> Return an HttpResponseRedirect to the appropriate URL for the arguments >> passed. >> >> The arguments could be: >> >> * A model: the model's `get_absolute_url()` function will be called. >> >> * A view name, possibly with arguments: `urls.reverse()` will be used >> to reverse-resolve the name. >> >> * A URL, which will be used as-is for the redirect location. >> >> Issues a temporary redirect by default; pass permanent=True to issue a >> permanent redirect. >> >> a redirect reason can be specified using the `reason` optional parameter >> """ >> redirect_class = HttpResponsePermanentRedirect if permanent else >> HttpResponseRedirect >> return redirect_class(resolve_url(to, *args, **kwargs), reason=reason) >> >> It does not affect any previous implementation. >> only impact could be if somebody has decided to pass on to a specific page >> the kwarg `reason` >> >> which is extremely minimal risk, and should be anyway easily detected >> through already present testing >> >> Do I have go ahead to propose a PR? >> >> -- >> 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 view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/71d5d7a0-da83-468b-8abb-96478fdcc0e4n%40googlegroups.com. > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAMyDDM2PNsHB3OOxS18MJQncN0NkQu-bdYE8Pua%2BhazgOemp4Q%40mail.gmail.com. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/WKaaJBvTePkT-bTTQjpBV6KtiYiNUT_Vmud99WI4SSyEIeGNYEG9v_xBRftUXFGHXUkEc7O5BtCKI8CsIQ8BeQDZaG3xji-SR2q0ctbZOaI%3D%40lilyf.org.
