[PEP8] Acronyms in class names should be uppercase

[Ben Davis]

According to PEP8, under "​Descriptive Naming Styles":

When using abbreviations in CapWords, capitalize all the letters of the abbreviation. Thus HTTPServerError is better than HttpServerError.

Django is currently inconsistent in this, as we have django.http.HttpResponse as well as django.utils.html.HTMLParser. With the deprecation framework, we should be able to change this without much trouble. I've attached some files that have the class names and the files in which they occur. I've separated them out into core, contrib, and tests, as we might not care to bother with the ones in contrib and tests. The ones in core are as follows:

CsrfToken -> CSRFToken
CsrfTokenNode -> CSRFTokenNode
CsrfViewMiddleware -> CSRFViewMiddleware
DefusedXmlException -> DefusedXMLException
EnsureCsrfCookie -> EnsureCSRFCookie
EnsureCsrfToken -> EnsureCSRFToken
HttpRequest -> HTTPRequest
HttpResponse -> HTTPResponse
HttpResponseBadRequest -> HTTPResponseBadRequest
HttpResponseBase -> HTTPResponseBase
HttpResponseForbidden -> HTTPResponseForbidden
HttpResponseGone -> HTTPResponseGone
HttpResponseNotAllowed -> HTTPResponseNotAllowed
HttpResponseNotFound -> HTTPResponseNotFound
HttpResponseNotModified -> HTTPResponseNotModified
HttpResponsePermanentRedirect -> HTTPResponsePermanentRedirect
HttpResponseRedirect -> HTTPResponseRedirect
HttpResponseRedirectBase -> HTTPResponseRedirectBase
HttpResponseServerError -> HTTPResponseServerError
Json -> JSON:
JsonResponse -> JSONResponse
RssFeed -> RSSFeed
StreamingHttpResponse -> StreamingHTTPResponse

[Tim Graham]

Please post to the mailing list about this. As it will probably affect 99% of projects, it's definitely not a decision to be taken lightly. While updating is probably a simple find/replace for most people, anyone who wants to support Django 2.0 (when the old versions would be dropped) as well as Django 1.7 (before the new versions would be added) will need to add a lot of try/except to handle both import styles. I'm not convinced purity beats practicality in this case.

[Tim Graham]

Consider also the trove of code snippets scattered across the internet which will no longer be copy and pastable due to bad imports.

[Vidir Valberg Gudmundsson]

Backwards incompatiability will be inevitable with Django 2.0 (as far as I know at least). So I suspect that this wouldn't be the only situation where try/except would be required if you want to support Django <2.0 AND 2.x.

That said if we want to adhere to PEP8 in this case, why shouldn't we also do that in other cases (like max 79 character line limit)? It would require quite a big overhaul of the code base though :)

Bottom line: I'm a big fan of PEP8 because it sets a baseline for code maintainability - but as timo says, this is more of a purity vs. practicality issue than pro/con PEP8.

[Claude Paroz]

Replying to valberg:

Backwards incompatiability will be inevitable with Django 2.0 (as far as I know at least).

No, unless absolutely required, I don't think we plan bigger incompatibility issues than for other releases, hopefully!

I will raise my -1 flag for this. But as Tim said, you can try to get support on the developers mailing list, and reopen if you get some consensus.

[Aymeric Augustin]

It would have been nice to get this right when we introduced these APIs, but now that they exist, changing them is not worth the code churn. -1 too.