| 146 | | Right now when using Django it is not uncommon to need to look at the docs just to see what a function returns or what the arguments type is. While this has been proposed a few times now, the Python typing ecosystem has improved making this more viable. While there are some areas where this would be difficult and may even hurt the experience due to Django's complexity like the ORM. I feel that there are some parts like the request, response object, path, class-based views, etc that would greatly benefit from this. |
| 147 | | |
| 148 | | This has been discussed before, most recently https://forum.djangoproject.com/t/revisiting-types-in-django-dep-14/37832. |
| | 146 | Right now, when working with Django, it’s quite common to refer back to the documentation just to understand what a function returns or what types its arguments expect. Although this idea has been proposed several times before, the Python typing ecosystem has matured significantly, making it a more practical direction today. There are certainly areas — particularly the ORM — where typing can be challenging or may even introduce complexity that outweighs the benefits. However, other parts of Django, such as request and response objects, URL routing, and class-based views, stand to gain clear usability improvements from better type support. |
| | 147 | |
| | 148 | We see [https://forum.djangoproject.com/t/revisiting-types-in-django-dep-14/37832/11 this comment] by Simon Charette as a good starting point for gradually introducing types, with the ORM being an especially valuable area where typing could help contributors reason about the codebase more effectively. The scope would include defining the necessary protocols and applying them throughout the ORM. This effort would also involve exploring CI integrations for type checking and deciding how types should be presented in the documentation — whether they should appear in every relevant definition, only in selected examples, or be omitted entirely. |