django.urls.reverse(): Add option to prevent escaping query params

[roniemartinez]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

We have migrated to 5.2 and loved the query param in reverse(). Thanks for adding this feature.

We recently encountered a limitation with this feature preventing us from using "unescaped" characters in the URL. For example in Stripe checkout (see https://docs.stripe.com/payments/checkout/custom-success-page?locale=en-GB), we need curly braces in the URL but this is being url-encoded in reverse().

Problem

Internally, reverse() uses urllib.parse.urlencode() as described in the documentation. The current implementation is not allowing "unescaped" characters like curly braces.

>>> urllib.parse.urlencode(query={"session_id": "{CHECKOUT_SESSION_ID}"})
'session_id=%7BCHECKOUT_SESSION_ID%7D' 

What we want (as Stripe's doc says) is to have unescaped curly braces. This can be obtained in urlencode with safe param as:

>>> urllib.parse.urlencode(query={"session_id": "{CHECKOUT_SESSION_ID}"}, safe="{}")
'session_id={CHECKOUT_SESSION_ID}'

Request or proposal

request

Additional Details

No response

Implementation Suggestions

[github-actions]

Thank you roniemartinez for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[carltongibson]

Hi @roniemartinez — thanks for the ticket.

I've added a 👎 — just to say why, I don't think we should be adding passthrough kwargs to reverse — we're expanding the API surface area for ever smaller use-cases.

For its whole life, if you needed query params you could just add them after calling reverse. Yes, we've added the convenience helpers¹ but if you need to customise the underlying call to urlencode then I think just dropping back to the old way is the way forward.

If I wanted this, I'd implement a wrapper that called reverse and then added the query params as I needed for my project, rather than expanding the default API.

I hope that makes sense.

Footnotes

1. Arguably we shouldn't have done that. Query params and fragments are not part of Django URL patterns, so adding them is not part of the job of reversing from a URL name, but 🤷 ↩