Opened 15 months ago

Closed 15 months ago

Last modified 15 months ago

#22895 closed Cleanup/optimization (wontfix)

[PEP8] Acronyms in class names should be uppercase

Reported by: bendavis78 Owned by: nobody
Component: Uncategorized Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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

Attachments (3)

rename_classes_core.txt (14.0 KB) - added by bendavis78 15 months ago.
rename_classes_contrib.txt (1.2 KB) - added by bendavis78 15 months ago.
rename_classes_tests.txt (591 bytes) - added by bendavis78 15 months ago.

Download all attachments as: .zip

Change History (8)

Changed 15 months ago by bendavis78

Changed 15 months ago by bendavis78

Changed 15 months ago by bendavis78

comment:1 Changed 15 months ago by timo

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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.

comment:2 Changed 15 months ago by timo

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

comment:3 follow-up: Changed 15 months ago by valberg

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.

comment:4 in reply to: ↑ 3 Changed 15 months ago by claudep

  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:5 Changed 15 months ago by aaugustin

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.

Note: See TracTickets for help on using tickets.
Back to Top