|Version 5 (modified by lukeplant, 22 months ago) (diff)|
Cruft that has accumulated in Django that would be nice to see fixed in Django 2.0
This page is for vague or broad ideas, and is in addition to the definite plans on the deprecation timeline.
Form validation/model forms/model saving
It is a bit complex at the moment - it would be nice to see an API that wasn't constrained by backwards compatibility like the current one was.
The ordering of a stack of request/view/response/exception middleware is pretty complex. Why do we actually need all these different types of middleware? We could actually write all the middleware as view decorators - simple callables that take a view function and return a view function (this is proved by the fact that you can convert middleware into decorators). The middleware stack could become a list of decorators that are globally applied. This brings up the need for how to handle exceptions to the global list of middleware - and how to handle nicely the case of 'sub-views'.
The CsrfViewMiddleware stops per-request upload handlers being added - ticket #14182. The workaround is ugly.
Inappropriate template names
Although TEMPLATE_FILE_EXTENSION was removed in  / , some templates have the wrong extension as a leftover from the way it previously worked. django/contrib/admin/templates/registration/password_reset_email.html should be password_reset_email.txt
The ORM is limited by not having a proper SQL abstraction layer. Use of SQLAlchemy for this might be nice, but would be a big change.
We should get rid of TEMPLATE_STRING_IF_INVALID. It's never worked even for debugging, because so much breaks if you change it. It is very much like a php.ini setting.
- queryset vs query_set inconsistencies in APIs