> One big exception to PEP 8 is our preference of longer line lengths.
We’re well into the 21st Century, and we have high-resolution computer
screens that can fit way more than 79 characters on a screen. Don’t limit
lines of code to 79 characters if it means the code looks significantly
uglier or is harder to read.
I have two issues with this:
1. It says that you don't have a limit of 79 characters, but it doesn't
say what you do instead. Is a line that is 1000+ characters acceptable?
1. It seems to imply that this PEP 8 rule is outdated and that there is
absolutely no reason whatsoever that anybody should follow it in a Django
project these days. It's even worded in kind of a condescending manner, in
my opinion. However, many developers prefer to have multiple files open
side by side. For example, they might have a models.py and views.py file
open side by side, or even multiple views of the same file open side by
side. The limit of 79 characters is helpful here. I would suggest taking
out the "21st Century" bit which seems to be there to justify Django not
following this PEP 8 rule, but, as I've pointed out, it doesn't really
justify it.
--
Ticket URL: <https://code.djangoproject.com/ticket/23395>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_tests: => 0
* version: 1.6 => master
* easy: 0 => 1
* needs_docs: => 0
* stage: Unreviewed => Accepted
Comment:
Hi nrogers64,
I agree with you that this text needs updating. As far as I know, the
current guideline is actually to keep lines within 79 characters unless it
doesn't fit, in which case it is ok to make longer lines. Clarity goes
above following the character limit.
Maybe just delete that one sentence and make it:
One exception to PEP 8 is our opinion on line length. Don’t limit lines of
code to 79 characters if it means the code looks significantly uglier or
is harder to read.
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:1>
* type: Uncategorized => Cleanup/optimization
Comment:
I agree that the tone is too snarky and FYI, pep8 was recently amended
regarding line lengths:
> Some teams strongly prefer a longer line length. For code maintained
exclusively or primarily by a team that can reach agreement on this issue,
it is okay to increase the nominal line length from 80 to 100 characters
(effectively increasing the maximum length to 99 characters), provided
that comments and docstrings are still wrapped at 72 characters.
(http://legacy.python.org/dev/peps/pep-0008/#maximum-line-length)
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:2>
Comment (by timgraham):
Perhaps outside the scope of this ticket, but I'd like to propose adopting
a max line length of 120 as that's the width of code review in GitHub.
Anything longer requires horizontal scrolling which makes review more
difficult. We could use flake8 to enforce this, however, it'll require a
lot of cleanup as we currently have ~1700 lines longer than that. I'll
attach an initial patch to show how long strings can be restructured.
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:3>
Comment (by collinanderson):
I use 120 (119) characters personally, again, because of github.
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:4>
* keywords: => afraid-to-commit
Comment:
I've marked this ticket as especially suitable for people following the
'''Don't be afraid to commit tutorial''' at the DjangoCon US 2014
sprints. If you're tackling this ticket, please don't hesitate to ask me
for guidance if you'd like any, either here or on the Django IRC channels,
where I can be found as ''EvilDMP''.
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:5>
Comment (by EvilDMP):
See https://groups.google.com/d/msgid/django-developers/8772de23-2970-4b60
-91ae-f5817f9b2bac%40googlegroups.com.
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:6>
Comment (by timgraham):
I'm working on the updates in `django/` and I've split up the test updates
into 3 files. Please claim one by commenting here if you want to work on
it.
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:7>
Comment (by nrogers64):
Tim, the only issue I have with your proposed wording at django-developers
is this:
> Documentation, comments, and docstrings should be wrapped at 79
characters.
As stated by bmispelon, PEP 8 says:
> For code maintained exclusively or primarily by a team that can reach
agreement on this issue, it is okay to increase the nominal line length
from 80 to 100 characters (effectively increasing the maximum length to 99
characters), provided that comments and docstrings are still wrapped at 72
characters.
Also, I'm not sure if Carl is correct or not in this statement that he
made:
> With recent updates to PEP 8 to accommodate longer lines, the stated
policy is no longer an exception to PEP 8
The quote from PEP 8 shown above seems to imply that you can go up to 99
characters if you want to, but no more than that. Maybe I'm
misinterpreting that, though.
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:8>
Comment (by carljm):
Replying to [comment:8 nrogers64]:
> Also, I'm not sure if Carl is correct or not in this statement that he
made:
>
> > With recent updates to PEP 8 to accommodate longer lines, the stated
policy is no longer an exception to PEP 8
>
> The quote from PEP 8 shown above seems to imply that you can go up to 99
characters if you want to, but no more than that. Maybe I'm
misinterpreting that, though.
You're right; I didn't re-check the PEP and mis-remembered it as allowing
up to 120, not 100. So allowing up to 120 remains an exception to PEP 8.
Thanks for the correction.
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:9>
Comment (by timgraham):
I've updated the proposed wording in
[https://github.com/django/django/pull/3158 this PR] which also fixes long
lines in `django/`.
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:10>
Comment (by Tim Graham <timograham@…>):
In [changeset:"1101467ce0756272a54f4c7bc65c4c335a94111b"]:
{{{
#!CommitTicketReference repository=""
revision="1101467ce0756272a54f4c7bc65c4c335a94111b"
Limited lines to 119 characters in django/
refs #23395.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:11>
Comment (by mcgeeco):
Hi guys, first-time contributor here. Am I right in saying that this patch
has been applied and that this ticket can be closed? Sorry if I'm missing
something.
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:12>
Comment (by bmispelon):
There are still some lines longer than 120 characters, that's why this
ticket still hasn't been closed.
You can find those lines by running `flake8 --select=E501` (you need to
install the `flake8` package first).
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:13>
Comment (by berkerpeksag):
https://github.com/django/django/pull/3421
I left two instances untouched:
* django/db/migrations/loader.py:115:120: E501 line too long (133 > 119
characters)
* django/db/migrations/autodetector.py:432:120: E501 line too long (166 >
119 characters)
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:14>
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:15>
Comment (by Tim Graham <timograham@…>):
In [changeset:"c9178ef17a0e1070f5a25096d8e13385d404dc92"]:
{{{
#!CommitTicketReference repository=""
revision="c9178ef17a0e1070f5a25096d8e13385d404dc92"
Limited lines to 119 characters in django/{contrib,db}.
Refs #23395.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:16>
Comment (by Tim Graham <timograham@…>):
In [changeset:"d73c7e5db66b7c149db59e07bc4c6253629cf907"]:
{{{
#!CommitTicketReference repository=""
revision="d73c7e5db66b7c149db59e07bc4c6253629cf907"
[1.7.x] Limited lines to 119 characters in django/{contrib,db}.
Refs #23395.
Backport of c9178ef17a (to decrease chance of backport conflicts) from
master
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:17>
* has_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:18>
* owner: nobody => JosephLeon
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:19>
* owner: JosephLeon =>
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:20>
* owner: => AmiZya
* status: new => assigned
* cc: amizya@… (added)
Comment:
I'll take care of this.
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:21>
* status: assigned => closed
* resolution: => fixed
Comment:
Doesn't seem much value here in addressing the line lengths unless we can
also exclude migration directories from being checked because the auto-
generated code there often has very long lines. Excluding `*/migrations/*`
as done before 9d30412a5ad1c72b3d319b4c2bceacb53a0ff1da, however, prevents
us from detecting other issues, especially in `django/db/migrations`. I
don't think listing all migrations directories in flake8 exclude would be
useful as an alternative, so unless anyone finds a solution, I think we
can close this.
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:22>
* status: closed => new
* resolution: fixed =>
Comment:
Let's try this using autopep8 to manually format migration files in order
to limit line length. I am getting tired of commenting about line length
on pull requests, so automated enforcement seems worthwhile.
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:23>
Comment (by dodobas):
One way to deal with migrations is to exclude `*/0*.py` which will not
exclude `django/db/migrations`. The option also excludes some more
esoteric migrations like
`./tests/migrations/migrations_test_apps/conflicting_app_with_dependencies/migrations/0002_second.py`
and similar.
AFAICT, `find -wholename '*/0*.py'`, no other files in Django repository,
start with `0` and end with `.py` so it should be safe enough to use
Other than that, there are ''only'' 15 occurrences of E501 in migration
files, 1018 problems remain :)
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:24>
Comment (by timgraham):
I think it can be useful to run flake8 checks on migrations -- especially
when writing them manually as in the case of data migrations. So I think
fixing those 15 cases either manually or automatically would be ideal.
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:25>
* cc: dodobas@… (added)
Comment:
ok, so just to confirm we want to modify/refactor all lines that result
with E501, in the Django master branch, right?
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:26>
Comment (by timgraham):
Correct. I'd suggest to start with the instances in `django/` to get a
feel for any style decisions. Then you can proceed to `tests/`. Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:27>
Comment (by dodobas):
Pull request: https://github.com/django/django/pull/5224
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:28>
* needs_better_patch: 0 => 1
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:29>
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"b1e33ceceda1e75ff68c7deed8f6659683a195d3" b1e33ce]:
{{{
#!CommitTicketReference repository=""
revision="b1e33ceceda1e75ff68c7deed8f6659683a195d3"
Fixed #23395 -- Limited line lengths to 119 characters.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23395#comment:30>