Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths
On Sun, Apr 18, 2010 at 4:11 PM, Maciej Stachowiak m...@apple.com wrote: That reminds me, we should turn off the 80-column limit on bugs.webkit.org - there's no need for it to hard-wrap your text. Great, I was wondering about that. I filed a report for that here: https://bugs.webkit.org/show_bug.cgi?id=37792 Thanks, --Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths
I wanted to add a couple comments and a question to this discussion. On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak m...@apple.com wrote: I haven't contributed to WebKit's Python code yet, but I will say that I agree with Eric's sentiments here. 80-column limit is archaic and pointless. No one is developing WebKit on a vt220. Note that there are contexts where the limit does come into play that the user might not have as much control over, for example pasting into the body of an e-mail or into the comment box in bugs.webkit.org. Take a look at these two comments for example (which, incidentally, are about crash logs rather than code): https://bugs.webkit.org/show_bug.cgi?id=23558#c4 https://bugs.webkit.org/show_bug.cgi?id=36707#c1 So non-Python developers know, one argument for treating Python differently (aside from PEP8) is that the language supports a syntax for continuing lines to the next line that other languages don't (implied line continuation). Finally, just to clarify, which parts of PEP8 are we discussing ignoring? PEP8 has more specific guidelines for docstrings and how they should be formatted. For instance, it also contains this guideline in addition to the blanket 79-character limit: For flowing long blocks of text (docstrings or comments), limiting the length to 72 characters is recommended. --Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths
On Apr 18, 2010, at 12:33 PM, Chris Jerdonek wrote: I wanted to add a couple comments and a question to this discussion. On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak m...@apple.com wrote: I haven't contributed to WebKit's Python code yet, but I will say that I agree with Eric's sentiments here. 80-column limit is archaic and pointless. No one is developing WebKit on a vt220. Note that there are contexts where the limit does come into play that the user might not have as much control over, for example pasting into the body of an e-mail or into the comment box in bugs.webkit.org. That reminds me, we should turn off the 80-column limit on bugs.webkit.org - there's no need for it to hard-wrap your text. That being said, we've lived for years with the fact that C++ code may get wrapped badly in these contexts and it hasn't really been an issue. Take a look at these two comments for example (which, incidentally, are about crash logs rather than code): https://bugs.webkit.org/show_bug.cgi?id=23558#c4 https://bugs.webkit.org/show_bug.cgi?id=36707#c1 So non-Python developers know, one argument for treating Python differently (aside from PEP8) is that the language supports a syntax for continuing lines to the next line that other languages don't (implied line continuation). Finally, just to clarify, which parts of PEP8 are we discussing ignoring? PEP8 has more specific guidelines for docstrings and how they should be formatted. For instance, it also contains this guideline in addition to the blanket 79-character limit: For flowing long blocks of text (docstrings or comments), limiting the length to 72 characters is recommended. I'm happy to let the people who hack on Python most decide whether a column limit is appropriate and if so which ones. Cheers, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths
bike-shedding
I think 80 columns is a waste of time and hurts readability.
Instead of being smart about when we wrap code, 80 adheres to a
blanket rule, discourages long variable/function names, and needlessly
expands code vertically ignoring modern wider-than-long monitors.
The optparse code which was recently re-wrapped is one example of 80c
fail. Impossible to tell in the wrapped version which arguments are
actually being listed (first argument to the function) because your
eye can't parse the start of each line.
That said. I'd rather have you and Adam and Chris all working on the
Python than have folks lose interest due to code wrapping. If the
consensus is 80c, I'll learn to deal. :)
The choice is either:
A. no wrapping rule to match the rest of WebKit
B. 80c to match the official PEP8 spec (and Google code).
I've chosen A. in the past. Mostly to match my own personal bias I'm sure.
-eric
/bike-shedding
On Wed, Apr 14, 2010 at 5:02 PM, Dirk Pranke dpra...@chromium.org wrote:
Hi all,
As I'm sure the discussions in the webkit meeting over the past two
days made clear, it looks like most of our non-C++ code is getting
written in Python. Back in January, Adam Barth posted this thread [1]
where I thought it was agreed we would attempt to follow PEP 8 ([2] -
the standard Python style guide) faithfully.
The one (somewhat) controversial aspect of that style guide is that it
requires a 79-column wide line length.
More recently, as part of implementing a style checker for Python code
[3], some have advocated that we should not follow that particular
restriction, because (a) the WebKit C++ style guide does not follow
that restriction, and (b) there is a reasonable amount of Python code
that does not follow the rule today and would have to be brought into
compliance. In particular, it was asked that we disable the long-line
check until at least the existing code was brought into compliance.
As far as (b) goes, there are currently (as of r57510) 1533 long lines
out of the 35,616 lines found under WebKitTools/Scripts/webkitpy,
occurring in 120 out 193 .py files. Most of the files that have any
long lines have less than five [4].
As far as disabling the check goes, I rather firmly believe that if we
wish to follow an ~80 column line-length limitation, the check needs
to be on by default, or else those who aren't used to this convention
will not follow it and the problem will get worse, not better (as
evidenced by [5]).
So, do we want to follow an 80-column limit for Python code, or not,
and if we do, should we enforce the rule by default or not?
If the concern is the existing code base I also (reluctantly)
volunteer to fix the long lines, if that influences the decisions.
Although I personally believe that code that is less than 80 columns
wide is easier to read and easier to maintain for a variety of
reasons, I mostly volunteer to do this because it's just not many
lines of code and I believe that having style guidelines that aren't
followed are a Very Bad Thing and hence the fact that we have existing
violations is a bad reason in this case to argue for not following the
rule.
Note that I do not particularly wish to argue the merits of this
particular style choice, just make (and document) a decision. It's a
religious position and the interweb is littered with existing
arguments pro and con that we would likely just rehash here. I raise
the issue at all only because I had thought that we made a decision
and then it was changed in relative obscurity in a bug, rather than
after being discussed here, whch struck me as not the right way to do
this sort of thing.
-- Dirk
[1] https://lists.webkit.org/pipermail/webkit-dev/2010-January/011423.html
[2] http://www.python.org/dev/peps/pep-0008/
[3] https://bugs.webkit.org/show_bug.cgi?id=33639
[4] Stats:
% find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
\*.py | wc -l # 193 .py files
% find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
\*.py | xargs wc -l # 35,316 lines of code
% find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
\*.py | xargs awk '{ if (length($0) 79) printf(%s:%d %s\n,
FILENAME, FNR, $0);}' # all of the long lines
% find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
\*.py | xargs awk '{ if (length($0) 79) printf(%s\n, FILENAME);}'
| sort | uniq -c | wc -l # 120 files w/ long lines
% find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
\*.py | xargs awk '{ if (length($0) 79) printf(%s\n, FILENAME);}'
| sort | uniq -c # distribution by file
[5] https://bugs.webkit.org/show_bug.cgi?id=37586
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths
On Apr 16, 2010, at 1:48 PM, Eric Seidel wrote: bike-shedding I think 80 columns is a waste of time and hurts readability. Instead of being smart about when we wrap code, 80 adheres to a blanket rule, discourages long variable/function names, and needlessly expands code vertically ignoring modern wider-than-long monitors. The optparse code which was recently re-wrapped is one example of 80c fail. Impossible to tell in the wrapped version which arguments are actually being listed (first argument to the function) because your eye can't parse the start of each line. That said. I'd rather have you and Adam and Chris all working on the Python than have folks lose interest due to code wrapping. If the consensus is 80c, I'll learn to deal. :) The choice is either: A. no wrapping rule to match the rest of WebKit B. 80c to match the official PEP8 spec (and Google code). I've chosen A. in the past. Mostly to match my own personal bias I'm sure. I haven't contributed to WebKit's Python code yet, but I will say that I agree with Eric's sentiments here. 80-column limit is archaic and pointless. No one is developing WebKit on a vt220. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths
(I have contributed but not often.) I also agree with 80 columns hurts readability. It doesn't take much looking to show a lothttp://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py#L135of lineshttp://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py#L259 thathttp://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py#L305 demonstratehttp://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/run_webkit_tests.py#L326 thishttp://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/layout_tests/rebaseline_chromium_webkit_tests.py#L449. However, I understand the desire to just take PEP8 whole. Once you decide to throw away one item, why not argue about any other (I tend to think 80 columns is the only thing that should be thrown out.) Sincerely, dc86ed7c29395f2b0863967f5350dfca4151be9d On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 16, 2010, at 1:48 PM, Eric Seidel wrote: bike-shedding I think 80 columns is a waste of time and hurts readability. Instead of being smart about when we wrap code, 80 adheres to a blanket rule, discourages long variable/function names, and needlessly expands code vertically ignoring modern wider-than-long monitors. The optparse code which was recently re-wrapped is one example of 80c fail. Impossible to tell in the wrapped version which arguments are actually being listed (first argument to the function) because your eye can't parse the start of each line. That said. I'd rather have you and Adam and Chris all working on the Python than have folks lose interest due to code wrapping. If the consensus is 80c, I'll learn to deal. :) The choice is either: A. no wrapping rule to match the rest of WebKit B. 80c to match the official PEP8 spec (and Google code). I've chosen A. in the past. Mostly to match my own personal bias I'm sure. I haven't contributed to WebKit's Python code yet, but I will say that I agree with Eric's sentiments here. 80-column limit is archaic and pointless. No one is developing WebKit on a vt220. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths
I think having longer lines of code hurts readability. There is lots of typographic evidence to back this up ( e.g. http://webtypography.net/Rhythm_and_Proportion/Horizontal_Motion/2.1.2/. Of course, the typographic commentary applies to text rather than code, and most text isn't indented, but I still think it's right). Even where the monitors are wider than they are tall argument goes, I prefer to use that space for multiple columns of text, because even if you do allow 80 char lines, most lines are shorter and hence you have a lot of wasted space. Granted, it is a combination of factors. I come from a C-based lineage of 2-space indentation, short variable names, and 8-character function names. Those all combine to make an 80- character line length workable. People who come from a 4-space (or greater) indentation, and the long variable-names style of Java or C++-with-templates will tend to see things differently. -- Dirk On Fri, Apr 16, 2010 at 3:09 PM, David Levin le...@chromium.org wrote: (I have contributed but not often.) I also agree with 80 columns hurts readability. It doesn't take much looking to show a lot of lines that demonstrate this. However, I understand the desire to just take PEP8 whole. Once you decide to throw away one item, why not argue about any other (I tend to think 80 columns is the only thing that should be thrown out.) Sincerely, dc86ed7c29395f2b0863967f5350dfca4151be9d On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 16, 2010, at 1:48 PM, Eric Seidel wrote: bike-shedding I think 80 columns is a waste of time and hurts readability. Instead of being smart about when we wrap code, 80 adheres to a blanket rule, discourages long variable/function names, and needlessly expands code vertically ignoring modern wider-than-long monitors. The optparse code which was recently re-wrapped is one example of 80c fail. Impossible to tell in the wrapped version which arguments are actually being listed (first argument to the function) because your eye can't parse the start of each line. That said. I'd rather have you and Adam and Chris all working on the Python than have folks lose interest due to code wrapping. If the consensus is 80c, I'll learn to deal. :) The choice is either: A. no wrapping rule to match the rest of WebKit B. 80c to match the official PEP8 spec (and Google code). I've chosen A. in the past. Mostly to match my own personal bias I'm sure. I haven't contributed to WebKit's Python code yet, but I will say that I agree with Eric's sentiments here. 80-column limit is archaic and pointless. No one is developing WebKit on a vt220. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
