Add `getbool()` to request.query_params (QueryDict)

I’d like to request that getbool(key) be added so that the value of query params can be casted to boolean automatically.

It is conventional to control the behaviour of endpoints using certain query params such as include_names=true. However, user may provide any of these:

  • truthy values: “1”, “true”, “T”, “y”, “True”, “TRUE”, …
  • falsy values: “0”, “”, “None”, “null”, “n”, …

I’ve been largely relying on a helper function similar to this (fastapi-events/fastapi_events/ at f44705b4031435d42f6e34bcf635c5d69f8bfdff · melvinkcx/fastapi-events · GitHub) to handle the conversion, but it’d be great if Django could support this out of the box.

Similar features are offered by frameworks like flask (see: Data Structures — Werkzeug Documentation (3.1.x))

Based on preliminary research, I believe it can simply be added to django.http.QueryDict as a method. I wouldn’t mind working on this as I already have a working workaround.

P/S: while I’m a long-time user of Django, this is my first attempt to request a feature, please let me know if I’m following the rules here.Thanks.

The way to handle this is with a form, and a BooleanField. The form’s job (together with its widget) is to take values from the data dict, and try to convert them to the appropriate type, and in so doing make sure they’re valid.

You can wrap that in a helper, but it’s two lines to define the form, and another couple to call it.

I don’t think we should add a secondary path for extracting, converting and validating data from requests.

See django/django/forms/ at d59066b90c2ef91a956c6682ed3d25bbb31bf216 · django/django · GitHub

Django Filter provides a slightly different version: django-filter/django_filters/ at 920a79ff401eb87946a2a6593bee767a7cfb2fa0 · carltongibson/django-filter · GitHub


I commonly use url params for debugging/feature flagging. I don’t use a form. I think the single getbool function is too specific while being easy enough to write. To me it seems like a nice improvement to query params to make a type castable and defaulted “get” method like werkzeug has in the op. Otherwise, I will continue to copy and paste a few functions around.

In my case, I use Django rest framework, so no forms are involved. I wanted this method to avoid having to copy and paste the helper function all around.

You should still use a form to validate (and transform) the data from the request, even if you’re not using the HTML rendering side of it.

(The primary role of forms is data sanitation. That they render HTML too is an added bonus.)

1 Like

@carltongibson Aside from the OP, unless I am missing it, I’m surprised that there’s no example in the docs parsing request.GET into a form. There is a GET and POST section that mentions using a form for query parameters. What do you think about adding an example to the forms documentation? I think it might be obvious to us (especially if we’ve gone further and used things like django-filter), but maybe it’s not very obvious to new users.

I think that’s a good idea, yes. :+1: