[Django] #22895: [PEP8] Acronyms in class names should be uppercase
Django
--------------------------------------+--------------------
Reporter: bendavis78 | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Uncategorized | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+--------------------
According to PEP8, under "[http://legacy.python.org/dev/peps/pep-0008/
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
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22895>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: bendavis78 | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: master
Component: Uncategorized | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timo):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22895#comment:1>
Django
Reporter: bendavis78 | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: master
Component: Uncategorized | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22895#comment:2>
Django
Reporter: bendavis78 | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: master
Component: Uncategorized | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22895#comment:3>
Django
Reporter: bendavis78 | Owner: nobody
Type: | Status: closed
Cleanup/optimization | Version: master
Component: Uncategorized | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by claudep):
* status: new => closed
* resolution: => wontfix
Comment:
Replying to [comment:3 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22895#comment:4>
Django
Reporter: bendavis78 | Owner: nobody
Type: | Status: closed
Cleanup/optimization | Version: master
Component: Uncategorized | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/22895#comment:5>