This thread is going where the OP didn't want it to go. Personal preference has already been decided to vary greatly. Seems to be about 50/50. Obviously THAT won't change. I was looking for objective arguments, not subjective ones. Arguing over *how* to break lines is actually a pretty strong argument that time is wasted spent on such issues. A longer line width would reduce these arguments, since less would need to be wrapped. So far, let me do a tally of objective arguments, just to keep this thing rational: New facts supporting 80 character line width: 1) Most conventional printers in portrait format can print 80 characters nicely in a line. 2) New netbooks have less width on their screens, making 80 characters nicer. (This actually probably calls for an even narrower width if this is a big concern) 3) If the code is standard library code, given that we have some folks out there who still write with 80 character line widths, then that code should still be 80 characters to fit the Least Common Denominator. 4) 2 space indentations reduce the preceding whitespace on each line by 50%, making 80 characters more reasonable. (and obviously, if people are using 2 space indents, horizontal space was at a premium). Also it appears from context that Google uses 2 space indents. 5) Older editors might have trouble handling greater than 80 character widths, including older terminal emulators. New facts supporting greater than 80 width: 1) Comment blocks are even more limited than originally thought, especially if following the PEP 8. 2) The standard library generally needn't leverage OO as much as code using it (in fact, much of the stdlib is procedural in nature), thereby making the stdlib less wide by nature. This is true of any core library...it is generally simpler code reused most often. Complex business logic, scientific programming, etc. also tends to need longer variable names since these notions can't be called simply "tool", but what type of tool and in an environment with many "tools" this name gets longer to be more descriptive. Other new facts: 1) Around 200 lines of code even within the standard library start at the 10th indentation level (40 characters gone already) 2) Around 10 percent of unique variable names even within the standard library have 15 characters or more 3) The origin of 80 character limit widths came from punch cards Of course, the original facts still remain (with original fact #7 held out as a weaker point, but still remains the only scientific study mentioned thusfar). What did I leave out? - Aaron On Thu, May 21, 2009 at 9:59 AM, Raymond Hettinger <python@rcn.com> wrote:
[Lie Ryan]
This is how I will write program if we have 160 character limit:
def foo(f, a, b, c): return [[((f(x, y) * i, i) if i % 2 else 0) for i, x in enumerate(a) if f(y, x) == a + x] for y in [c(z) for z in range(a, a * b + c, c)]]
except there will be no line breaks...
I love list comprehension so much that I often _unconsciously_ write a very complex list comprehensions. 80-character convention acts as a reminder to consider refactoring.
that makes sense to because your example starts close to the left margin. What I'm more concerned about is lines that start many tabs deep. Those become awkward, causing you to wrap them differently than if they were not tabbed. So, I think the 80 char limit should be relaxed only when there is a bunch of whitespace to the left. Your cues for refactoring and coding style should not depend on the initial level of indentation.
Raymond
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas