| | 125 | == Experimental feature flags and processes == |
| | 126 | |
| | 127 | || Difficulty || Hard |
| | 128 | || Size || 350hr |
| | 129 | || Mentors || Andrew Miller(need confirmation) |
| | 130 | || Key Skills || Python, Django |
| | 131 | |
| | 132 | The current development process of Django is slow. This is in part due to our commitment to backwards compatibility. |
| | 133 | This means it is hard to test a new feature API directly in django/django because if we get it wrong we can't easily change it. |
| | 134 | An experimental feature flag would help us overcome this, possibly making Django development faster |
| | 135 | |
| | 136 | Complete discussion here: https://github.com/django/new-features/issues/3 |
| | 137 | |
| | 138 | |
| | 139 | == Add types to parts of Django == |
| | 140 | |
| | 141 | || Difficulty || Hard |
| | 142 | || Size || 350hr |
| | 143 | || Mentors || Thibaut Decombe (need confirmation) |
| | 144 | || Key Skills || Python, Django |
| | 145 | |
| | 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. |
| | 149 | |
| | 150 | This would also help solve many of the issues here https://groups.google.com/g/django-developers/c/at-G0hZrfXE. |
| | 151 | |
| | 152 | Github reference: https://github.com/django/new-features/issues/23 |
| | 153 | |