Code


Version 5 (modified by lukeplant, 22 months ago) (diff)

--

Django Warts

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.

Middleware

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'.

Ticket 14182

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 [2700] / [2809], 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

Limited ORM

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.

Templates

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.

Naming issues

  • queryset vs query_set inconsistencies in APIs