80 character line width vs. something wider

I realize that this is a religious debate which has gone on for many centuries. I appeal to the scientific aspects, with a distinct avoidance of preference and emotion. Preference might be easily explained by "right brain" vs "left brain" preference, but either way, it is merely a preference and I want to stick to facts. Here is a list I have compiled of facts which support a wider than 80 character line width standard (in Python, specifically). Please add to them, subtract from them, or add to the other side of the debate, but please avoid the usage of the word "readable" (which implies preference), unless you are referring to a scientific study of readability, which would be great. 1) Python is three things which the standard was not designed for: One: Object Oriented. Two: Not Hungarian notation Three: Mandatorily uses *whitespace* as its defintion for code blocks. Let me explain each one in a bit more detail: Object Oriented: Because it is not functional-style programming, but instead OO, you have to give defintion as to what object type you are using before using it. This makes definitions and usage longer than in functional programming (when 80 character widths were invented). PhazeMonkey.Hardware.FrameSource.Abstract.Framegrabber is an example (and not an extreme one) of a class (55 characters already) in a rather large code base. Not Hungarian: Not only is Python not Hungarian (in general), but the PEP-8 specifically tells us to use longer, more descriptive variable names. hasInstrumentControllerPhaseDither is an example. Many variables are 15-20 characters and oftentimes longer. How many of these variables can you fit into a line if we are limited to 80? Whitespace: Python is very unique in that it *uses* whitespace for code blocking. It turns out to be very useful, since it visually cues the reader where code blocks begin and end by mandate. This creates many situations where code *starts* at the 10th indentation (40 characters in our standard, 80 characters in some Python standards). Even in normal "great design" mode (which takes more time again), you can't help it....your code starts at the 6th indentation level often. (28 characters, more than 30% of 80 characters already gone. Now how many variables or class names can you fit?) Whitespace (2): Because Python uses whitespace as its sole method of code blocking and because this is the visual cue for code blocks, wrapping lines obfuscates this and makes the reader think about whether this whitespace was there for a code block, or a line-wrap. Thinking about intention of code slows us down. 2) Many of the libraries that are widely used do not adhere to the 80 character width line standard. wxPython, NumPy and Boa Constructor are a few, but I'm sure there are many, many more. Many libraries do adhere to 80 character line width as well. However, a library which is written in 80 characters still fits the paradigm of those which are wider and therefore backward compliant. In other words, if your tools are geared toward 80 character line widths and you are now looking at a wider width, things become quite difficult. The other way around is fine. 3) Writing new code in 80 character line widths takes more time. If I have to worry about hitting this width, I have to de-concentrate my efforts of writing logical code and concentrate instead on how exactly to format this line of code (where to break it, etc....there are a number of rules attached to wrapping lines of code). Then I have to re-concentrate on the actual task at hand. Alternatively, I can code it up without worrying, then when convenient, take some time to reformat to 80 character width. Either way, more time. 4) Code searching. IDEs have powerful searching features. They list all the lines of a file (or files) which match the string you are searching for. If things are in one line, this search is meaningful and you can read it like you can code. If a line of code actually spans two (or more) lines of code, the search is no longer contextually useful and you have to click on each item to see what's actually going on. This feature is used heavily in many environments (especially large code bases) to save time, but time is either lost finding the actual context of a found string, or the search tool is avoided altogether because it does not provide meaningful results (i.e. a predictive waste of time) 5) Monitors are getting bigger, wider, cheaper. This allows us to have two files, side-by-side on a screen that are *both* 120 character width (or even wider), without changing font sizes. 6) Tools are cheap. Time isn't. Get a second monitor, get a more powerful editor, do whatever it takes to save time. If viewing more information at one time is important, then we should try to make that possible with technology, not time. 7) Python is designed to be written more like English than other programming languages. English is written horizontally, not vertically. In furtherance to an attempt to make "readability" an objective argument, here is a scientific study which finds that greater character width lines improve readability: http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp.<http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp> To summarize, the study found that of the choices of 35, 55, 75 and 95 character lengths, 95 was able to be read the fastest. Please note that they did not try 115, 135, etc. and that they found their maximum data point at the farthest edge of their study. One can conclude that they probably should have gone even further to determine where (if ever) it tapers off. This study focuses on reading English, not on reading code. But given the first sentence of this point, it should at least loosely correlate. At any rate, it's an attempt at something scientific on the issue. Thanks for the time spent reading this long-ish post. Thanks for your feedback if you provide it. - Aaron Aaron Rubin Software Engineering Manager 4D Technology

I'll bite. On Tue, May 19, 2009 at 12:43 PM, Aaron Rubin <aaron.rubin@4dtechnology.com> wrote:
If you are using more than 5 or 6 levels of indentation you may be doing something wrong. I would guess that your methods are too complex or maybe you are violating the SRP.
I'd like to see an example of your variable names. I don't use hungarian notation and my name are usually under 10 characters.
I'd like to see an example of where using 10 levels of indentation is good. I'll bet that it's not easy to test.
I partially think you're right. Although I have the same problem with long lines that have multiple levels of parens.
I don't really have this issue. The few seconds a day that I waste formatting code are nothing near the time I waste on YouTube :-)
I would actually like to see tools changed to make this better. Maybe similar to the way unified diff shows a few lines of context.
Sure I guess. I am typing this on my EEE 900 which won't like much more than 90 chars. But even at work I put multiple 80 char wide windows side by side.
Agreed. Use Vim with 80 characters and you will rock out code like never before. I hear Emacs is good too. What are you currently using.
7) Python is designed to be written more like English than other programming languages.
That's news to me. On another note when we hire new developers I often hear this argument. Once they start coding in Python and using good OO/TDD techniques they realize that it really doesn't matter. Out of curiosity how much Python coding do you do? -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek

On Tue, May 19, 2009 at 10:45 AM, MRAB <google@mrabarnett.plus.com> wrote:
You can't always control the names you're working with. In our case, we're writing .NET-based code that uses a lot types originally defined in C#. The standard in C#-land tends to be much more verbose than in Python, and definitely presents some challenges when trying to keep lines under 80 chars. I imagine that Jython code has a similar issue when interoperating with Java. -- Curt Hagenlocher curt@hagenlocher.org

While aesthetics is a highly subjective matter, good code tends to have a "paucity begets expressiveness" feeling. I.e. experienced programmers seem to have developed an intuition for finding succinct names for entities -- names that convey the underlying meaning to the onlooker at first glance. That style is accompanied by good structure with groups of usually shortish lines with meaningful empty lines in between. The result is like good minimalist prose or a poem: a consistent piece of thinking, a pause, another piece that follows naturally from the previous. Aesthetically, this style contradicts with verboseness, long lines and generally cramming things together. The latter usually convey the image of uncertainty -- i.e. the writer is only yet trying to find a way of succinct expression, feeling a bit disoriented in the domain or language and wanting to hide the lack of confidence behind verbosity and pompous style. After all, Python has zen built in, so lets walk the path of 'import this' and revere the beauty of PEP-8 :). So, personally, I'm -0 (not that my opinion matters of course, and, after all, this is classic bikeshedding) even though quite a few of the previous arguments supporting longer lines are sensible.

Curt Hagenlocher wrote:
That's true. It's also a problem for people doing Cocoa with PyObjC. But who cares? If you want to break PEP8 for your own project, there's nothing to stop you. The only thing that PEP8 is binding on is what gets checked into the cpython source, and, for obvious reasons, that doesn't interact with C#-stuff or JVM-stuff or Cocoa-stuff to any significant degree. I'm not sure what the point of this debate is. If you want to use 500 chars per line, the interpreter won't complain. If you want to say that using more than 80 chars per line would make the cpython source read better, I would have to respectfully disagree. So, what's the problem?

On Tue, May 19, 2009 at 5:53 PM, Carl Johnson <cmjohnson.mailinglist@gmail.com> wrote:
But who cares? If you want to break PEP8 for your own project, there's nothing to stop you.
True. Unless -- hypothetically -- the architect decides that all the source in the project will follow PEP-8 and you want to do an end-run around the decision because you're tired of losing five minutes every few hours as a result of working out how to reformat a block of code to best respect the 80-char limit. *wink* -- Curt Hagenlocher curt@hagenlocher.org

Curt Hagenlocher <curt@hagenlocher.org> writes:
As pointed out elsewhere in this thread, very often the superior solution is not to re-*format* the same statement to fit, but to re-*factor* the code so it's less deeply indented or does less in each statement. And that re-factoring isn't lost time; it's saved time when later readers try to understand the code. -- \ “There was a point to this story, but it has temporarily | `\ escaped the chronicler's mind.” —Douglas Adams | _o__) | Ben Finney

Curt Hagenlocher <curt@hagenlocher.org> writes:
Yes, "refactor" is a much better word than "reformat" for what I was thinking.
Well, before deciding that, be aware that it already has a fairly specific meaning in programming terminology <URL:http://www.refactoring.com/> <URL:http://en.wikipedia.org/wiki/Code_refactoring>. -- \ “I believe in making the world safe for our children, but not | `\ our children's children, because I don't think children should | _o__) be having sex.” —Jack Handey | Ben Finney

So, it seems that support for an 80 character limit is rooted in a desire to have other people program differently than they do, somehow making their programs better just because they are adhering to an arbitrary limit on horizontal text width. That seems somewhat magical. Maybe the limit should be 40 chars, then everyone will have to refactor, and line wrap, and use smaller idents (like Google does), and use more abbreviated variable names. Maybe the origin of the 80 char limit isn't an anachronism. Maybe it had nothing to do with teletypes and low resolution CRTs. Perhaps, the programming gods of old were reaching into the future with certain knowledge that they were forcing everyone to do the right thing. Who knew? Raymond

On Wed, May 20, 2009 at 1:44 PM, Raymond Hettinger <python@rcn.com> wrote:
Or we can simply interpret the N-chars bound as a soft limit and feel free to exceed it by one character or three if it makes more sense. I am certainly not breaking a line for a single extra character. George

On Thu, 21 May 2009 03:44:15 am Raymond Hettinger wrote:
Can I remind you that the 80 character limit is for the standard library, not your own personal code? Use whatever limit you like in your own personal libraries, or no limit at all. If your productivity is enhanced by writing 100-character lines, or 300 for that matter, then go right ahead. Some people find their productivity is enhanced with an 80 character limit. There's nothing "magical" about this -- we've given some reasons. 80 character lines fit comfortably in email and printed pages without wrapping, they can be viewed even on small screens without horizontal scrolling, and, yes, some people find that this constraint enhances our productivity and so we use the same limit in our own code, not just the stdlib. We're not forcing you to do the same. The 80 character limit is a lowest-common denominator. Having a 36" high-resolution monitor, or the visual acuity to read 7pt text, should not be a prerequisite for reading the stdlib. For this common code base, forcing everyone to limit line length is less of an imposition than forcing everyone to deal with long lines.
No, 40 characters would be just foolish. The cost-benefit of constraints is not linear: there is a sweet-spot, where the cost is the minimum and the benefit is the maximum, and I believe that is around 80 characters, or possibly even a little shorter: I use a soft-limit of 70 characters in my own code, but I don't force that on anyone else.
What possible relevance is the origin? Standards can change their justification over time. Commons used to exist so that the peasants would have somewhere to graze their goats. Not a lot of people have goats any more, but we still have commons, only now they're called "parks". If the character limit didn't remain relevant, we'd remove it, but it is relevant: people do print out code onto paper, people do still have poor eyesight requiring larger font sizes, or small monitors, or large monitors with four side-by-side editor windows. -- Steven D'Aprano

On Wed, May 20, 2009 at 4:02 PM, Steven D'Aprano <steve@pearwood.info>wrote:
I see part of the problem now. People perceive the PEP-8 as the way they should write all code, not just the standard library. It seems to be passed around as the be-all-end-all, but in fact it might only represent what is good for the standard library and only the standard library. Perhaps commercial code bases, or other types of code bases should not blindly subscribe to this ideal. The 80 character width limit seems like this might be a candidate for consideration of flexibility depending on some critical factors. However, having a line width *limit* seems like a uniformly good one...to say which specific character to break up the lines might depend greatly (or solely) on the tools you (or your company) use(s). As time marches forward and email editors don't wrap (mine doesn't), printers are used less (which is already happening), etc. then standards for core libraries will probably change as well. Forward thinking is important and backwards compatibility is also important. Writing code at 80 characters takes more time, but it definitely ensures that any future standard will be compatible with it (i.e. a future 100 character width standard won't be offended by 80 character wrapped lines). So, at some point, I would predict 100 will become more prudent for standard libraries in Python and then (assuming the language is still thriving after many many years) it might become 120, etc. But it will just take time. Either way, the style for coding within a non-standard library might want to be revisited much sooner. In other words, programming to a standard which is common to all people who use it means you probably must accommodate the lowest common denominator. This would not be true for anything but the standard library.
This is a minor point, but I would argue that the origin is relevant. It helps to realize what assumptions are being made about the code base, which may or may not be true anymore. In the case of a "park", it is obvious that the origin was questioned at some point, since "parks" needn't have grass anymore. (where grass=80 character limit width)

Aaron Rubin wrote:
I see part of the problem now. People perceive the PEP-8 as the way they should write all code, not just the standard library.
I think they're reasonable guidelines to follow for code that you intend to publicise, for the same reasons that they're good for the stdlib. But nobody is going to beat you up with a stick if you don't follow them to the letter.
Yes, but the relevant question remains "Do we still need it, and if so, why?", not "It's old, so it must be out of date by now, surely?" -- Greg

On Wed, 20 May 2009 17:44:54 -0700 Aaron Rubin <aaron.rubin@4dtechnology.com> wrote:
On Wed, May 20, 2009 at 4:02 PM, Steven D'Aprano <steve@pearwood.info>wrote: As time marches forward and email editors don't wrap (mine doesn't),
That makes your mail editor a throwback. Used to be, none of them wrapped. Then an 800 lb gorilla of a company decided to ignore what the RFCs said, and made their mailer act like there WP products and wrap text. It's hard to find a modern mailer that doesn't wrap.
printers are used less (which is already happening), etc. then standards for core libraries will probably change as well.
But PDAs and Netbooks are being used more and more.
Um, I'd say it holds for pretty much every other open source project done in Python, excepting those that are targeted for some specific platform. I.e. - if you're writing scripts for a high-end CAD program, then you get one set of assumptions about the working environment. But if you're developing on and for N60, you get a completely different set. The problem is that on it's good days, this is a bikeshed issue. On it's bad day out and out religious. Choosing to follow PEP-8 so as to not waste time discussing it is a rational choice for any group working in Python. It's certainly better than no standards at all! <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On Wed, May 20, 2009 at 6:30 PM, Mike Meyer <mwm@mired.org> wrote:
I use gmail.
You can't possibly make a case that programming on either of these devices should be what we should cater to. I want to program on my Palm phone as well, but I have to accept that the world won't try to accommodate me, but the other way around.
I am trying to discern between a code base which must cater to all, and a code base which mustn't. An open source project is akin to a widely used closed source project. What they share is they don't need to cater to *the* least common denominator, but instead *a* least common denominator, which gives them more flexibility.
But choosing to pinpoint particular aspects which do not appear to make much sense and attempt to further understand the rationale behind it, so as to assess whether it is worth it to follow those aspects is very worthwhile. Whether the entire community accepts it is another thing. The entire community appears to be quite divided on this issue and rightfully so...we appear to be in the middle of change :) Otherwise, there wouldn't be so much debate on the topic.

On Wed, May 20, 2009 at 9:55 PM, Aaron Rubin <aaron.rubin@4dtechnology.com> wrote:
I like programming on my EEE. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek

On Wed, May 20, 2009 at 10:32 PM, Aaron Rubin <aaron.rubin@4dtechnology.com> wrote:
I don't think I'm expecting to be catered to because of the netbook. To me 80 just works well and is in the current PEP. So I'm happy. I just think that the people that say using 80 characters takes more time is using a very crappy editor. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek

On Wed, 20 May 2009 18:55:11 -0700 Aaron Rubin <aaron.rubin@4dtechnology.com> wrote:
Nope, you don't make things more difficult for everybody else just to make things easier for them. On the other hand, you can't possibly disenfranchise them, either - which means that a change that makes things harder on people using them needs to benefit everyone else enough to make up for it.
But the PSL is just another open source project. It has no requirement to cater to all, or to *the* lcd, any more than any other such project. In fact, it clearly doesn't, as it certainly never catered to people working in the Python implementation for the old Palm series III devices, or the N60 implementation, etc.
Oh? Doesn't seem to be much different than last time (I saw it, anyway - it may have happened again during a hiatus). Lots of people with strong personal preferences, but the best real reason around is "we've always done it that way". Of course, everyone also seems to be forgetting one of the most important points in the PEP: But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask! But why not help things along even further, by cutting the length of what's probably the most common variable name in python by 50%, and replace "self" with "my". We can't shorten cls, but we can bring it into the same part of speach by making it "our". <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Aaron Rubin <aaron.rubin@4dtechnology.com> writes:
Perhaps. Or perhaps those style constraints were chosen for the standard library *because* they're widely applicable and make sense for Python code in general.
Indeed. Such forward thinking must take into account that devices with smaller and smaller displays are being used for viewing documents, including code.
You assume that human eyesight and capacity to comprehend complex syntax will also scale with the display resolution. That doesn't seem a well-supported assumption. I think average human ability to perceive lines of text, having remained pretty much constant over the history of computing so far, will tend to remain fairly constant for the foreseeable future, and hence the 80-column limit will continue to be a good standard for Python code. -- \ “Are you thinking what I'm thinking, Pinky?” “Uh... yeah, | `\ Brain, but where are we going to find rubber pants our size?” | _o__) —_Pinky and The Brain_ | Ben Finney

For what it's worth, I'm in favour of sticking with the current 80 character limit. It's really not hard to work with or accommodate. In my workplace, I go much wider, but we all have standard environments and it's no big deal. 80 characters looks narrow to me, but I can adjust, and it makes sense to use this as a common denominator for a widely-shared piece of code like the Python core libraries. As everyone has said, it works well in emails, funny terminals, vi, emacs, IDEs, can be easily used side-by-side with other open editors, etc. These 'special cases' seem very remote until you are suddenly confronted by them. For me, the most common is when telnetting / sshing into a foreign machine which assumes an 80-character width and the terminal emulation setting is a bit mucked up, so all of a sudden you can't resize to make use of your screen real estate. Trying to read code over such a link, or through a funny email client which wraps long lines, is awful and I'm happy to accommodate those people. Working with the 80-character limit is really easy in my editor, and it's certainly much easier to fit in with the existing style of a shared codebase than to have idiosyncrasies within sections that have been edited here and there. I don't think the 80-character limit in PEP-8 is doing many people a great deal of harm. Cheers, -T

I don't think the 80-character limit in PEP-8 is doing many people a great deal of harm.
FWIW, I posted two recurring examples of where it is awkward in normal python programming. One, raising exceptions with messages -- the message doesn't typically start until 30th column or so. Two, in unittests using self.assertRaises(SomeException, expr), the expr part doesn't typically start until the 35th column or so. Also, there is a problem with indented multiline string literals where the indentation is taking up space that will never be shown to the end-user. Indented comments and in-line comments are also space challenged. I think the Google example is instructive. Their two space tabs are not a natural preference for anyone I know. Instead, it is an accommodation born from trying to fit nested, indented code into 80 columns. I'm pretty much in agreement with the OP that going to 90 or 100 columns is a better solution. Of course, if Hollerith punch cards come back into vogue, then the OP's proposal won't work out so well ;-) Raymond

"Raymond Hettinger" <python@rcn.com> writes:
As was covered earlier in the thread, cases like that are why the following style makes sense for call parameters:: def error_emitter(): raise some.name.space.LongDescriptiveError( "Message for the error" " which can cross multiple lines if necessary", other, args)
Two, in unittests using self.assertRaises(SomeException, expr), the expr part doesn't typically start until the 35th column or so.
class FrobnicationTest(unittest.TestCase): def test_frobnicates_the_spangle(self): self.assertRaises( SomeException, expr) So neither of these use cases is materially harmed by an 80-column limit.
Given the available options for making code fit nicely within 80-column lines and 4-column indentation levels, and the benefits to be had from doing so, I don't agree with your position. -- \ “Never express yourself more clearly than you are able to | `\ think.” —Niels Bohr | _o__) | Ben Finney

On 20May2009 20:16, Raymond Hettinger <python@rcn.com> wrote:
I think the Google example is instructive. Their two space tabs are not a natural preference for anyone I know.
I regret to inform you that two space tabs are my preferred indentation. -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ To be positive: To be mistaken at the top of one's voice. Ambrose Bierce (1842-1914), U.S. author. The Devil's Dictionary (1881-1906).

Le Thu, 21 May 2009 12:41:20 +1000, Ben Finney <ben+python@benfinney.id.au> s'exprima ainsi:
You are certainly right here, but this applies to "busy" line-width, which is most often < 50 chars (left-side spacing excluded), even when overall line width is > 80. Breaking lines that sensibly mirror the semantics and hold less than 50 content characters, only because of an arbitrary right-side limit, prevents confortable reading. Also, most wider lines go over the limit because they contain long literals (strings, lists) which are not complex conceptually -- they just eat horizontal space. Breaking the line in such cases hinders human parsing, it does not help it. To sum up, the human parsing factor rather requires intelligently relaxing limits, not the contrary. Denis ------ la vita e estrany ------ la vita e estrany

If the character limit didn't remain relevant, we'd remove it,
My suggestion is to just bump it up a bit (perhaps to 100 chars). Docstrings and code for method definitions in Python typically start at two tabs deep. That means that most of the body of a program is in a somewhat narrow band. This most troublesome with string literals embedded in the code and with trailing comments. IMO, if a string literal is less than 80 chars, then cutting it midstring is an anti-pattern. Breaking the literals is awkward and uncomfortable. This seems to come-up often with error messages which seem to usually be defined several levels deep so that there isn't much space left for the message. class X: def Y(self): 'Comment' for something in Z: if somecondition: raise Exception(some_message % somevalue) Another problematic area is with unittests: class TestX(unittest.testcase): def test_z(self): self.assertRaises(TypeError, real_code_starts_here) Both of those situations seem to lead to awkward line wrapping right in the middle of a literal or expression. It both cases, the literal or expression of interest starts without a whole lot of room left. Sometimes we're able to fit it in gracefully, sometimes not.
people do print out code onto paper
My experience with printing code is that vertical space is the main challenge. The unittest module for example takes at least 25 pages depending on how much you're willing to give-up margins and large type.
Some people find their productivity is enhanced with an 80 character limit.
Perhaps this is true, though I've not heard one jot of evidence to support it and certainly no evidence focusing on Python coding practices which are affected by the use of whitespace for control flow. Nor have I seen evidence of comparative productivity of 80 char limits versus 100 char limits. All we have is anecdotal evidence and personal tastes. What I have seen is a company where all of the Python programmers routinely moved into the 100 character range when necessary and it worked out fine. Also, I've seen plenty of code be made "pep-8 compliant" and not look any better for the effort. Raymond

Raymond Hettinger wrote:
My suggestion is to just bump it up a bit (perhaps to 100 chars).
If there's anything I'd suggest changing, it would be to reduce the recommended indentation from 4 chars to 2. That's what I use internally for my own code, and it seems to be a good compromise between readability and eating up too much width with indentation. -- Greg

Le Wed, 20 May 2009 18:02:54 -0700, "Raymond Hettinger" <python@rcn.com> s'exprima ainsi:
If the character limit didn't remain relevant, we'd remove it,
(to Steven) We definitely don't live in the same world ;-) In mine, any purely legacy trait change raises religious wars. People fighting against change _always_ find "good" reasons. That seems to be part of human nature (in the world I live in).
We could differenciate between overall line width and "busy" line width (from fist non-white). The latter may have a (recommanded) limit less than 80 characters. It should not be too wide for human overall comprehension (but optimum may vary greatly). Except for literals and probably some other issue (e.g. imported names*). About the former, we probably could define algorithms that nicely reformat code in a sensible manner, for printing or whatever physical constraint. Denis (*) Someone suggested to "import ... as ..." but in many cases it's wrong because other programmers cannot rely anymore on their knowledge of libraries. ------ la vita e estrany

spir schrieb:
And who determines if it *is* a purely legacy trait? Don't you think that these reasons may be valid when it isn't? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

There is, of course, a correct solution to this line length problem. The ideal maximum line length is dependent on how much horizontal space you've got, so the code should be automatically wrapped to your window size. That's how all other text displaying systems work, from html to word processors. It's just code that's the exception*. This would require good automatic wrapping, which is a bit more difficult for code than for English, but automatic reformatting utilities already exist. It would also require tool support, so everyone would need to use editors like emacs or something else that's programmable. Just your favorite notepad-on-steroids variant won't suffice anymore. Of course, it's only 2009 and this is all very much py-in-the-sky. (Though who knows what Python 6000 will bring...) * another exception are config files, but more and more people are writing gui config editors, which adapt to the window size, so these too are following the trend. The only backward compatible way I can think of to implement this is to tell your emacs or other programmable editor to automatically display files according to your window width, and wrap them to 80/whatever cpl in the on disk representation when you save. And add some magic so it only changes those parts of the file in the on disk representation that you actually edited, deal smartly with line numbering, etc, etc. Jan

Jan Kanis <jan.kanis@phil.uu.nl> writes:
It's also dependent on how different line lengths affect ease of rapid comprehension. As mentioned many times in this thread.
so the code should be automatically wrapped to your window size.
No, since that fails to account for the dependency I mention above. -- \ “Science is a way of trying not to fool yourself. The first | `\ principle is that you must not fool yourself, and you are the | _o__) easiest person to fool.” —Richard P. Feynman, 1964 | Ben Finney

OK. Again, this thread appears dead to the OP, since it has been delving into subjectiveness for quite a while now. If anybody has more objective arguments to propose, I would love to hear them. If not, then hopefully someone will read this thread and pick out the objective points for future consideration of this highly debated point. Remember that if Python is to remain a choice for future generations, its ability to be dynamic needs to remain. Times change, tools change. Languages must change as well. Making Python a hospitable environment for future generations to contribute will be important. This is what made my choice of Python 10 years ago an easy choice. Let's not forget to be dynamic so that others will make the same choice down the road. - Aaron On Fri, May 22, 2009 at 3:43 PM, Ben Finney <ben+python@benfinney.id.au<ben%2Bpython@benfinney.id.au>
wrote:

On Mon, 25 May 2009 12:35:18 -0700 Aaron Rubin <aaron.rubin@4dtechnology.com> wrote:
OK. Again, this thread appears dead to the OP, since it has been delving into subjectiveness for quite a while now.
Always a problem on those pesky interwebs :-).
And this is another example of topic drift. The OP wasn't suggesting a change to Python, so a claim that it must change is pretty clearly off topic. One thing that those espousing such a change keep forgetting is that the 79 character limit (it's not 80 - go read the PEP) isn't part of the language. It's part of a style guideline that describes what the community feels is a good style. Nothing actually forces anyone to follow it. The standard library includes code that violates the PEP, even in the public APIs (though the PEP-conforming variants have been made available recently). If you disagree with PEP 8, you're free to ignore all or part of it in your code. That won't keep the code out of the standard library if it's otherwise worthy and still readable. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On May 25, 2009, at 13:35 PM, Aaron Rubin wrote:
Personally, I would consider "objective arguments" to be controlled, repeatasble, studies with quantitative results. I've seen such studies about light-background-dark-foreground vs. dark-foreground- light-background, which is why I use the former now. I haven't seen such studies about line width, especially not with Python text as opposed to English text. I will therefore spare you my personal, subjective opinion about this topic. Regards, Zooko

On Tue, May 26, 2009, Zooko Wilcox-O'Hearn wrote:
Personally, I would be amazed to see any significant difference between the two foreground/background combinations you list. ;-) -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "In many ways, it's a dull language, borrowing solid old concepts from many other languages & styles: boring syntax, unsurprising semantics, few automatic coercions, etc etc. But that's one of the things I like about it." --Tim Peters on Python, 16 Sep 1993

On Tue, May 26, 2009 at 09:47:05AM -0700, Aahz wrote:
Entirely off topic by now, but these differences are more significant for e.g. dyslectic people. And these studies exist and are the reason exam papers in the UK are printed black on yellow etc. To be more no-topic, for as long as I've knowingly used computers my text editor window (and thus programming environment) has been 40x80 (emacs for me ;-)). Also having code no longer then 80 chars is nice when debugging on (serial) consoles, which does happen unfortunately. You're not always in your comfy development environment. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

On Tue, May 26, 2009, Floris Bruynooghe wrote:
In case it wasn't clear, Zooko gave exactly the same color combo for foreground/background, only reversed in ordering. It was a jest at his expense for the typo. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "In many ways, it's a dull language, borrowing solid old concepts from many other languages & styles: boring syntax, unsurprising semantics, few automatic coercions, etc etc. But that's one of the things I like about it." --Tim Peters on Python, 16 Sep 1993

On 2009-05-26 18:12, Aahz wrote:
Floris is obviously using a dark-foreground-light-background color scheme, or he wouldn't have misread that. :-) -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

On Tue, May 26, 2009 at 06:56:30PM -0500, Robert Kern wrote:
Oh, re-read that a few times before I finally saw it. Doh! I actually use both, light-before-dark on my terminals and dark-before-light on my editor. They're both so pretty... Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

Raymond Hettinger wrote:
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.

On Thu, May 21, 2009 at 9:04 AM, Lie Ryan <lie.1296@gmail.com> wrote:
hmm, the 80-character convention does not stop me from unconsciously writing really complex list comprehensions, I just write them like so: 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)]] not that that's really any better. I really don't mind the 80-character convention. I occasionally have problems with going over it, but most of the time it serves (as you point out) as a flag for something that probably needs refactoring. When I do go over it, it's normally only by a few chars. The other benefits of it, for me, is easily reading code in a terminal in the few cases I end up without X , and for opening multiple files in emacs with vertical-split. The latter is a huge benefit, and could still be done if the convention was upped to, say, 100 chars - but would start to get annoying with wrapping shortly after that. But yeah, this is all anectodal evidence and personal taste, as Raymond points out. The 80 char limit _had_ a practical reason for existing, and I don't doubt that there are people out there that are still using the (hard|soft)ware that caused the limit to be practical, but they're probably few and far between. I also haven't seen anything other than anectodal evidence and personal taste in favor of increasing the limit, which suggests to me that it should just stay how it is. It is just a convention after all.

Jeremiah Dodds <jeremiah.dodds@gmail.com> writes:
On the contrary, I find that *much* easier to grasp than the same statement on a single line. You have been required, by choosing to follow the 80-column limit, to choose points at which to break the line; and have responded by breaking it up into conceptually discrete chunks and indented to suggest the structure. This example is, for me, a very convincing (anecdotal) demonstration of why an 80-column limit is a good constraint to follow.
But yeah, this is all anectodal evidence and personal taste, as Raymond points out.
Yet it's also more than that; to call it “personal taste” is to imply that it's nothing more than aesthetics. If that's all it were, I'd care far less for changes in convention. I consider it rather more importantly a matter of software ergonomics, which should therefore not be changed unless there's good supporting evidence that the proposed change results in improvement. -- \ “A cynic is a man who knows the price of everything and the | `\ value of nothing.” —Oscar Wilde | _o__) | Ben Finney

On Thu, May 21, 2009 at 11:01 AM, Ben Finney <ben+python@benfinney.id.au<ben%2Bpython@benfinney.id.au>
wrote:
Oh, yes - I consider it much easier to read than the single-line equivalent. What I meant by "not that that's really any better" was more along the lines of "that statement should probably be refactored". It's very rare that I run into a case where a convoluted list comprehension like that isn't better written some other way. Sometimes I end up with stuff like that when I've made incorrect assumptions while designing a program, etc.
I tend to agree. That's very well-said.

Jeremiah Dodds wrote:
[clipped]
With the popularity of smaller netbooks, laptops, and other hand held computing devices going up, I think the 80 char limit guideline may still serve a good and practical purpose. So I'm for keeping it as it is on the principle that it is only a guideline and anyone can disregard it if it is advantageous for them to do so. Ron

[Lie Ryan]
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

Raymond Hettinger wrote:
On contrary, if the left margin causes me to struggle to keep lines below 80-char, it is an indication that the whole class/function could benefit from refactoring. It is rarely necessary to need more than 2 levels of initial (function level) indentation or 3 if you used closure: e.g.: class def def (closure) and any function that have more than another 2-3 level is an indication that it needs refactoring. class def with for if So in total, 3-5 levels are the maximum in any sane code. To me, 3-5 level is not that deep for 80-char to become a hindrance. Anyway, it seems people keep forgetting that PEP 8 is a guideline, not a syntax. I usually keep lines below 80, but I don't mind breaking them now and then if I think it is justified.

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:

[Aaron Rubin]
Around 200 lines of code even within the standard library start at the 10th indentation level (40 characters gone already)
Can you modify your script to show the full distribution (percentage of lines at the nth indentation level)? Also, I'm curious how much distribution differs between Lib/test vs Lib vs Lib/email. Raymond

On Fri, 22 May 2009 04:42:24 am Raymond Hettinger wrote:
I'd also like to see some information about the structure of said lines, e.g. are those 200 lines in a single giant block, or 200 blocks of one line each, or something in-between?
Also, I'm curious how much distribution differs between Lib/test vs Lib vs Lib/email.
I wonder whether some sort of source code analyser should be included in the std lib (or perhaps in Tools?). -- Steven D'Aprano

On Thu, May 21, 2009 at 12:59 PM, Raymond Hettinger <python@rcn.com> wrote:
I disagree. I find that highly nested code probably needs refactoring. The code in question is likely too complex and hard to test. Of course this is not always the case, just a general rule in my experience. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek

Le Tue, 19 May 2009 13:14:15 -0400, David Stanek <dstanek@dstanek.com> s'exprima ainsi:
I'll bite.
Nice to warn. Unfortunately, it won't not help making your reply helpful/pertinent/convincing. Too bad for the OP who precautiously & explicitely tried to avoid yet another religious war on a well-known hot topic, ain't it? Maybe next century... Denis ------ la vita e estrany

On Tue, May 19, 2009 at 10:14 AM, David Stanek <dstanek@dstanek.com> wrote:
See below for code example
I gave an example already in the snippet you quoted.
Regarding this and the other notion of 5 or 6 being the proper level of indentation: class a(object): def method1(simulation=False): try: if simulation: for x in range(10): if x>5: try: # here might begin some actual math, with two or three more levels of logic, interfacing with other libraries such as NumPy, etc. where you might need specific error handling except CustomError: # customer error handling i.e. the logic code *started* at the 7th indentation level. But I'm sure you can find plenty of examples where it might be more.
or responding to people's posts about character width issues ;)
Wing IDE.
Lots and lots and lots :) Started using Python over 10 years ago. Use it all day, every day. Love it :) Using good OO to me seems to accentuate the need for greater line widths (point #1) in a large project (i.e. classes need to be hierarchical in a big project, therefore in order to disambiguate, more characters are needed to refer to this class)

On Wed, 20 May 2009 03:53:33 am Aaron Rubin wrote:
On Tue, May 19, 2009 at 10:14 AM, David Stanek <dstanek@dstanek.com> wrote:
That's a red-herring. Functional programming is quite capable of 80+ character lines too: FetchFrameGrabber(ExtractAbstract(GetFrameSource(GetHardware(MakePhazeMonkey()))))
PhazeMonkey.Hardware.FrameSource.Abstract.Framegrabber is an example
Such a deeply hierarchical call is poor technique regardless of what each level represents: classes, modules, function calls, or something else. It is reasonable for parts of your code that understand PhazeMonkeys to know that a PhazeMonkey has Hardware, but it is completely unreasonable for that same section of code to rely on the existence of PhazeMonkey.Hardware.FrameSource.Abstract.Framegrabber. That sort of tight coupling between the top of the hierarchy and the bottom defeats the purpose of encapsulation. I see that in a later post, Aaron writes: "The Law of Demeter applies to objects referenced second-hand. The class name given is an example of a hierarchy of modules, not one class reaching through a second class to get at the class members it uses." That's an irrelevant objection. Demeter is a design principle: it applies to classes, namespaces, military units, corporate business units or any hierarchical structure. Of all the military blunders in World War I, the one they never made was for General Haig to call up the front line and say "Hello, let me speak to Private Baldrick. Baldrick, I want you to take your rifle and point it due east and use your index finger to pull the trigger at 1700 hours precisely." Besides, modules *are* objects:
Namely:
Far too complex in my opinion. That's best refactored into separate methods or functions. For example: class A(object): def simulated_method1(self): self._common() def method1(self): try: for x in range(5): self._metha(x) for x in range(5, 10): self._methb(x) self._common() except CustomError: self._fallback() def _metha(self, x): """Return function(x), for 0 <= x < 5.""" assert 0 <= x < 5 def _methb(self, x): """Return function(x), for 5 <= x < 10.""" assert 5 <= x < 10 That's (possibly?) longer code, but it comes in single-thought-sized chunks. Each method does one thing, rather than wrapping a whole bunch of loosely-related functionality into a single method. Another advantage is that it reduces the amount of test code you need. Instead of what could be an exponentially large number of possible paths through method1(), each individual method only has one or possibly two paths that need testing.
Namely "hasInstrumentControllerPhaseDither". Well, your naming conventions are yours, naturally, and you can use any convention you like, but I can't imagine ever willingly using a name like that. I would suggest that if you need to distinguish hasInstrumentControllerPhaseDither from (say) hasInstrumentWidgetPhaseDither, hasScannerControllerPhaseDither and hasInstrumentControllerAmplitudeDither in the one function, your function is far too complex, doing too many things, and should be split up into smaller single-purpose functions.
True enough for those editing on large monitors, AND who like viewing multiple files side-by-side. (Personally, I very rarely do, and then only when comparing two files line-by-line.) But have pity on those using a EEE or similar machine. Besides, if you can fit two 120-char wide files on screen, you can fit three 80-char wide files on screen. For what it's worth, although I've never needed to interoperate with code using .NET style guidelines or written a 100 KLOC program, I generally have very little difficulty in keeping 90% of my code below *seventy* characters per line, including four-space indents, and virtually all of the rest below eighty. The short line-length encourages me to refactor my code so that every function does one thing and one thing only. -- Steven D'Aprano

Aaron Rubin <aaron.rubin@4dtechnology.com> writes:
This is fairly clearly a contrived example. Can you give an example of actual in-use code which suffers from such deep indentation? I've no doubt you can produce such code, but it's far easier to discuss ways to improve (and *that* it will improve) an example of actual code than a contrived example.
i.e. the logic code *started* at the 7th indentation level.
This would almost certainly be improved by taking some of those deeply-indented parts and re-factoring them to separate functions. But again, it's hard to show that without a real example. -- \ “Holy uncanny photographic mental processes, Batman!” —Robin | `\ | _o__) | Ben Finney

Ben Finney <ben+python@benfinney.id.au> wrote:
From threading.py:
class Thread(_Verbose): def __bootstrap_inner(self): try: self.__ident = _get_ident() self.__started.set() _active_limbo_lock.acquire() _active[self.__ident] = self del _limbo[self] _active_limbo_lock.release() if __debug__: self._note("%s.__bootstrap(): thread started", self) if _trace_hook: self._note("%s.__bootstrap(): registering trace hook", self) _sys.settrace(_trace_hook) if _profile_hook: self._note("%s.__bootstrap(): registering profile hook", self) _sys.setprofile(_profile_hook) try: self.run() except SystemExit: if __debug__: self._note("%s.__bootstrap(): raised SystemExit", self) except: if __debug__: self._note("%s.__bootstrap(): unhandled exception", self) # If sys.stderr is no more (most likely from interpreter # shutdown) use self.__stderr. Otherwise still use sys (as in # _sys) in case sys.stderr was redefined since the creation of # self. if _sys: _sys.stderr.write("Exception in thread %s:\n%s\n" % (self.name, _format_exc())) else: # Do the best job possible w/o a huge amt. of code to # approximate a traceback (code ideas from # Lib/traceback.py) exc_type, exc_value, exc_tb = self.__exc_info() try: print>>self.__stderr, ( "Exception in thread " + self.name + " (most likely raised during interpreter shutdown):") print>>self.__stderr, ( "Traceback (most recent call last):") while exc_tb: print>>self.__stderr, ( ' File "%s", line %s, in %s' % (exc_tb.tb_frame.f_code.co_filename, exc_tb.tb_lineno, exc_tb.tb_frame.f_code.co_name)) exc_tb = exc_tb.tb_next print>>self.__stderr, ("%s: %s" % (exc_type, exc_value)) # Make sure that exc_tb gets deleted since it is a memory # hog; deleting everything else is just for thoroughness finally: del exc_type, exc_value, exc_tb else: if __debug__: self._note("%s.__bootstrap(): normal return", self) finally: # Prevent a race in # test_threading.test_no_refcycle_through_target when # the exception keeps the target alive past when we # assert that it's dead. self.__exc_clear() finally: with _active_limbo_lock: self.__stop() try: # We don't call self.__delete() because it also # grabs _active_limbo_lock. del _active[_get_ident()] except: pass Cheers, Cesare

"Cesare Di Mauro" <cesare.dimauro@a-tono.com> writes:
From threading.py:
That's a perfect example of doing too much in one function, thank you. Here's a first draft refactor for both making it easier to keep track of, and reducing the indentation as an added benefit:: class Thread(_Verbose): def _prepare_bootstrap(self): self.__ident = _get_ident() self.__started.set() _active_limbo_lock.acquire() _active[self.__ident] = self del _limbo[self] _active_limbo_lock.release() if __debug__: self._note("%s.__bootstrap(): thread started", self) if _trace_hook: self._note("%s.__bootstrap(): registering trace hook", self) _sys.settrace(_trace_hook) if _profile_hook: self._note("%s.__bootstrap(): registering profile hook", self) _sys.setprofile(_profile_hook) def _bootstrap_run(self): try: self.run() except SystemExit: if __debug__: self._note("%s.__bootstrap(): raised SystemExit", self) except: self._unhandled_exception() else: if __debug__: self._note("%s.__bootstrap(): normal return", self) finally: # Prevent a race in # test_threading.test_no_refcycle_through_target when # the exception keeps the target alive past when we # assert that it's dead. self.__exc_clear() def _unhandled_exception(self): if __debug__: self._note("%s.__bootstrap(): unhandled exception", self) # If sys.stderr is no more (most likely from interpreter # shutdown) use self.__stderr. Otherwise still use sys (as in # _sys) in case sys.stderr was redefined since the creation of # self. if _sys: _sys.stderr.write("Exception in thread %s:\n%s\n" % (self.name, _format_exc())) else: # Do the best job possible w/o a huge amt. of code to # approximate a traceback (code ideas from # Lib/traceback.py) exc_type, exc_value, exc_tb = self.__exc_info() try: print>>self.__stderr, ( "Exception in thread " + self.name + " (most likely raised during interpreter shutdown):") print>>self.__stderr, ( "Traceback (most recent call last):") while exc_tb: print>>self.__stderr, ( ' File "%s", line %s, in %s' % (exc_tb.tb_frame.f_code.co_filename, exc_tb.tb_lineno, exc_tb.tb_frame.f_code.co_name)) exc_tb = exc_tb.tb_next print>>self.__stderr, ("%s: %s" % (exc_type, exc_value)) # Make sure that exc_tb gets deleted since it is a memory # hog; deleting everything else is just for thoroughness finally: del exc_type, exc_value, exc_tb def _limbo_lock_stop(self): with _active_limbo_lock: self.__stop() try: # We don't call self.__delete() because it also # grabs _active_limbo_lock. del _active[_get_ident()] except: pass def __bootstrap_inner(self): try: self._prepare_bootstrap() self._bootstrap_run() finally: self._limbo_lock_stop() -- \ “Apologize, v. To lay the foundation for a future offense.” | `\ —Ambrose Bierce, _The Devil's Dictionary_, 1906 | _o__) | Ben Finney

On May 19, 2009, at 1:43 PM, Aaron Rubin wrote:
What they found is that text set on one single column of 95 cpl was faster to read than if it was less cpl. That was pretty obvious for the get go in the way they organized the text (divided in many screens with next/previous button). They should have either focused on texts that fit on one screen or provided two or even tree columns for the smaller text. I theorize that python has much more semantic information density than common english news (and in a completely different dimension) so you can't possibly extrapolate the results of that paper. -- Leonardo Santagada santagada at gmail.com

FWIW, I think Google solves this problem by using two space idents. Though I suspect your note was trolling, I agree with you and find the 80 character width to be an anachronism. I've seen too many god-awful mid-phrase line wraps and trailing backslashes that could have been avoided with something a bit longer (like 100 chars). In addition to code wrapping, I'm a little bugged by indented comment blocks with 80 character line wrapping so that fewer than 40 chars are available per line of text. It sucks to update those comment blocks and then rewrap them so that a diff cannot easilly show what had changed. The days of 25x80 black and white CRTs are gone. Raymond

Le Tue, 19 May 2009 11:15:31 -0700, "Raymond Hettinger" <python@rcn.com> s'exprima ainsi:
I think about the same way on this topic. +1 on relaxing guidelines constraints
The days of 25x80 black and white CRTs are gone. (Except I remember well green on black, and orange on black as well, CRTs ;-)
Denis ------ la vita e estrany

On Tue, May 19, 2009 at 1:15 PM, Raymond Hettinger <python@rcn.com> wrote:
Though I suspect your note was trolling, I agree with you and find the 80 character width to be an anachronism.
I find the long lines in my code are not as contrived as the thread so far suggests: t = t[:m.start()] + t[m.end():] # ok because we're iterating in reverse sys.stderr.write("js-build: WARNING: Due to COMMAND_MODE madness, this can fail on Leopard!\n" "js-build: Workaround is to upgrade to Python 2.5.2 or later.\n") allVariants = [_m + _r + _x for _x in ('', 'x') for _m in ('', 'm') for _r in ('r', 'd')] yield Message(parseTime(attr(u'received')), who, text(msg), isAction) while self.node is not None and self.node.nodeType == self.node.TEXT_NODE: And some examples in Mercurial: if err.errno not in (errno.ENOENT, errno.ENOTDIR, errno.EINVAL): ('U', 'noupdate', None, _('do not update the new working directories')), self.parent[id] = self.lastbranch.get(branch, 'bad') -j

Jason Orendorff writes:
Jason, if you want to show code with long lines, please use an email tool chain that doesn't wrap those long lines. Somewhere along the way you're getting extra line breaks inserted. -- \ “Facts do not cease to exist because they are ignored.” —Aldous | `\ Huxley | _o__) | Ben Finney

Jason Orendorff writes:
I do find several of them unreadable. Brief classification:
t = t[:m.start()] + t[m.end():] # ok because we're iterating in reverse
Plausible usage; gets the comment out of the control flow, which is good.
sys.stderr.write("js-build: WARNING: Due to COMMAND_MODE madness, this can fail on Leopard!\n" "js-build: Workaround is to upgrade to Python 2.5.2 or later.\n")
Ditto, for arbitrary I/O content.
allVariants = [_m + _r + _x for _x in ('', 'x') for _m in ('', 'm') for _r in ('r', 'd')]
I find that hard to read. With more than two clauses, I prefer to put them on separate lines anyway: allVariants = [_m + _r + _x for _x in ('', 'x') for _m in ('', 'm') for _r in ('r', 'd')]
yield Message(parseTime(attr(u'received')), who, text(msg), isAction)
Mildly hard to read; I tend to skip the details of a complex call on one line, and have to go back if I need them. Eg, in review I would very like miss a typo where the 2nd and 3rd arguments are (incorrectly) swapped unless I read that line token by token. I'm much less likely to make that mistake for yield Message(parseTime(attr(u'received')), who, text(msg), isAction) although I grant that at 81 characters for the long line, the two-line format is distinctly uglier.
while self.node is not None and self.node.nodeType == self.node.TEXT_NODE:
Unecessary for me. I would use a sentinel whose nodeType is SENTINEL_NODE for this anyway, rather than None. Note that there are two kinds of arguments presented. One is that the long line isn't necessary. That obviously has to depend on higher- level issues of style (eg, using None vs. a special nodeType as a sentinel), so definitely YMMV, and if a lot of people in your project prefer the None-style, that's an argument *for* long lines. The other is that I find some hard to read, and if there are more than a very few in your project who feel as I do, long lines can have a *negative impact* on review.

Le Wed, 20 May 2009 11:38:55 +0900, "Stephen J. Turnbull" <stephen@xemacs.org> s'exprima ainsi:
One wall I run into with lines < 80 characters is, paradoxally, that I miss width for lines I want to break (!). The issue is that, ~ in order to have logical, comprehensible, layout, ~ and to avoid messing up with python's own indent the continuation lines have to align with items on the same logical level in the first line, for instance: try: my_final_result = finalResultProducer(arg1_from_abunch_of_args, args_should_align_properly, [so, what, if, they, re, compound]) except AttributeError, error: raise ResultError( "foo ......... bar" "<--All message text lines should start here." %(String, interpolation, argument, list, as, well) ) Note that I started the try...except at a rather low level (3). Denis ------ la vita e estrany

On 5/19/09, Jason Orendorff <jason.orendorff@gmail.com> wrote:
FWIW, I would find it easier to read all but one of these if they were broken into multiple lines -- and that is regardless of what monitor I happened to be using at the time.
My idiom here is to take out the literal, at least to its own line. For example: msg="""\ js-build: WARNING: Due to COMMAND_MODE madness, this can fail on Leopard! js-build: Workaround is to upgrade to Python 2.5.2 or later. """ sys.stderr.write(msg)
self.parent[id] = self.lastbranch.get(branch, 'bad')
This was the only one where a line break might hurt readability for me, and I still suspect a rewording would make it easier to read. -jJ

On Tue, May 19, 2009, Raymond Hettinger wrote:
The days of 25x80 black and white CRTs are gone.
That's half-true; the problem is that windows more than eighty columns wide cover up too much of other windows. I have generally compromised on thirty lines as being the right balance of information per window versus not covering up too much of other windows. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines." --Ralph Waldo Emerson

Aaron Rubin writes:
The reporting of the statistical analysis borders on deceptive, and the sample is very small. The procedure is described in insufficient detail, as well. I would not rely on this study (and in fact the study itself reports that other studies have come up with results preferring "medium" lengths of 55-60). In general, I think your arguments mostly come down to "the line length limitation makes it noticably harder to write code quickly" plus a little bit of "longer line lengths are maybe a little faster to read". But I think that's the wrong place to put the emphasis. It's much more important to make the code easy to read and understand. The study you cite reports that 55% of the subjects considered the 95 cpl format the most uncomfortable. I think that's a good reason to be wary of increasing line length.

I think that, aside dogmatisms, we can try and clarify when, how, and why line breaks and/or longer lines can help us writing comprehensible code. This is, or should be, the purpose of defining style guidelines. My position reads as follows -- expansion, critics, comments welcome. -1- Use line breaks. Line breaks often help showing the logics of code deeper than, but in a similar way as, python's forced indentation. This is done by splitting complexity into smaller bits visually presented in parallel. They can also help organising literals in a sensible manner. Both often play together to offer "easy to read" (whatever this means) code. This is common for function definitions and function calls, nested container literals, multiline output strings,... -2- Use long lines. One the other hand, sometimes we wish not to break a line because this would break the logics alltogether. The breaking place would just be arbitrary if there is no logical structure in what we have to split (just to comply with guidelines); so that instead of helping readibility, line breaks introduce "semantic distortion" in such cases. This is common for longer flat containers, single-line string literals and probably some other cases. -3- How to use line breaks, then? <my personal problem> While I love using line breaks when they make sense, I often to have no other choice than disregarding the 80-chars rule *precisely when breaking lines*. The issue is that, in adition to indentation, the continuation line(s) must _visually_ align with items at the same _logical_ level. This level can well be 20 or 30 characters farther on right from the indentation level: try: my_final_result = finalResultComputer(arg1_from_abunch_of_args, args_should_align_properly, [so, what, if, they, re, compound]) except AttributeError, error: raise computeError( "foo ......... bar" "<--All message text lines should start here." %(String, interpolation, argument, list, as, well) ) [If we do not respect alignment, then the code is semantically wrong. It's like if we would (have to) write for instance: if condition: task1.................................... |80 char limit task2........................................ task3....................................... just to save some indent characters.] -4- Narrow text even in wide lines! This raises the question of available free width. With both indentation and alignment coming into play, we often have less than 40 characters left. All arguments pro or contra broader lines for legibility thus are irrelevant, because we have rather narrow content anyway ;- -5- Style Then comes the question of style. Numerous authors have argued that "readibility" or "legibility" simply are masked aliases for "familiarity". On the other hand, a programmer should be able to express things the way s/he really thinks them; to express his or her real meaning and intent. A programmer must be able to feel easy with his or her own code! So that there is a balance to be found between uniformity and personal ease. As a summary, I would like a recommandation rather than a rule. A note that shows how (0) short line _content_ usually is a sign of good code (*), (1) line breaking can help expressing code structure, (2) but this can require rather big overall line widths, whith leading spacing (3) and in some cases single-lines simply better mirror semantics. (*) How much, typically? Denis ------ la vita e estrany

spir <denis.spir@free.fr> writes:
It's for this reason that I advocate indenting continued lines *one* level, and not this hideously large increase in indentation for a single step. Simply break at the opening container character, and indent a single level to make all the contents line up:: try: my_final_result = finalResultComputer( arg1_from_abunch_of_args, args_should_align_properly, [so, what, if, they, re, compound]) except AttributeError, error: raise computeError( "foo ......... bar" "<--All message text lines should start here." % (String, interpolation, argument, list, as, well)) -- \ “I put instant coffee in a microwave oven and almost went back | `\ in time.” —Steven Wright | _o__) | Ben Finney

Le Wed, 20 May 2009 19:40:31 +1000, Ben Finney <ben+python@benfinney.id.au> s'exprima ainsi:
Yes, I partially agree with you indentation mode. But to my eyes (maybe it's only me) the result (1) seems to suggest ordinary python indentation, which it is not and (2) does not make obvious what continuation lines belong to. This can be a bit improved (again, to my eyes) using ~ double indentation for continuation lines ~ closing sings (parens, etc) on their own line Which gives: try: my_final_result = finalResultComputer( arg1_from_abunch_of_args, args_should_align_properly, [so, what, if, they, re, compound] ) except AttributeError, error: raise computeError( "foo ......... bar" "<--All message text lines should start here." % (String, interpolation, argument, list, as, well) ) This looks acceptable -- even if 2 more lines are spent vertically (another relevant point). For any reason, while in general I really do not support C-like style, in these precise cases I find the final closing mark on its own really helpful (esp. where I placed it here). Denis ------ la vita e estrany

spir <denis.spir@free.fr> writes:
I beg to differ. Python indentation is inspired by the indentation that programmers do *anyway* to make the structure of their programs clearer. Some of it is syntactically significant, but that doesn't make the practice of indentation any less meaningful where it's not syntax. The indentation, in this case, is indicating that the indented lines are subordinate to the lines at an outer level of indentation.
and (2) does not make obvious what continuation lines belong to.
I think it's obvious that the continuation lines “belong to” the statement that begins on an outer level of indentation. This is, indeed, the entire point of indenting those continuation lines beneath the line which begins the statement, no?
I have no objection to either of those, except for a slight waste of space for no benefit that I can appreciate. Certainly not egregious like the original example. -- \ “Yesterday I told a chicken to cross the road. It said, ‘What | `\ for?’” —Steven Wright | _o__) | Ben Finney

On Wed, May 20, 2009, Ben Finney wrote:
That's almost what I do, except that I put the terminating container character on its own line to simplify adding and deleting arguments:: try: my_final_result = finalResultComputer( arg1_from_abunch_of_args, args_should_align_properly, [so, what, if, they, re, compound], ) except AttributeError, error: raise computeError( "foo ......... bar" "<--All message text lines should start here." % (String, interpolation, argument, list, as, well) ) This practice comes more from lists/dicts; I simply generalize it to arguments. You'll also notice that similarly I put a trailing comma on the last argument. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines." --Ralph Waldo Emerson

On Wed, May 20, 2009 at 5:40 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
I do this sometimes, but only if not every argument fits between the opening parenthesis and the 80-char limit. Otherwise, I typically indent them at the "(" level, i.e.: try: my_final_result = finalResultComputer(somelongname, otherlongname, [some, subexpression]) except AttributeError, error: raise computeError("foo ......... bar", "<--some message" % (interpolation, args)) George

Also, it's convenient to remember that you can wrap any expression in parentheses which can help in situations like this: raise ( ValueError ), ( "what were you thinking?" ) Using this approach, you can indent (or not) however you like. It's a convenient way to break up long lines and you can get improved readability as a side-effect. On Wed, May 20, 2009 at 9:44 AM, George Sakkis <george.sakkis@gmail.com> wrote:
-- Gerald Britton

On 5/19/09, Aaron Rubin <aaron.rubin@4dtechnology.com> wrote:
PhazeMonkey.Hardware.FrameSource.Abstract.Framegrabber
During the PEP for with, this was considered (as a competing meaning for "with"). There was some concern that it might be needed for integration with other frameworks, such as .net, java GUI code, etc. In the end, Guido rejected it because you can just do it with a temporary variable. frm=PhazeMonkey.Hardware.FrameSource frm.Abstract.Framegrabber
I just looked at a sampling of books from my shelf. The *longest* line length I found was 71 characters. I have seen (but can't find at the moment) studies showing that lines wider than a certain percentage of the visual field are problematic. The exact portion (and how many characters fit in it at a readable font) will vary from person to person; what is comfortable for you may already be very disruptive for a teammate -- and your savings from a longer line are small enough that this is one case where lowest common denominator should be given great weight. (Leading whitespace is much "cheaper" than actual text, but there is still some effort in sliding that focal window back and forth with the indent/dedent dance.) And of course, this concern with visual focal area already assumes that everyone will have windows as wide as yours and fonts as small; I can assure you that neither is true. The first person to need horizontal scrolling will lose more time than you saved. The first person using a window/terminal where the line wrapped on its own because it was too long will squander far more. -jJ

Jim Jewett schrieb:
I agree completely. I also find, and that is of course a subjective finding, that my "on-sight" estimation of code quality partly depends on line length. Code that looks "frayed" (forgive me if that's not the right word) immediately looks less "tidy" to me. Of course, other factors come into play, like the amount of whitespace applied, the consistency of indentation, the consistency and spelling in comments etc. These are all stylistic points, but in summa, the code itself more often than not turns out to confirm the first look assessment. This means that most decent Python programmers know PEP 8 and follow it. The reasons may be as simple as mindlessly following the established standard, but I suspect otherwise: if PEP 8 was completely unreasonable, a different standard would have emerged. 2¢-ly, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

I'll bite. On Tue, May 19, 2009 at 12:43 PM, Aaron Rubin <aaron.rubin@4dtechnology.com> wrote:
If you are using more than 5 or 6 levels of indentation you may be doing something wrong. I would guess that your methods are too complex or maybe you are violating the SRP.
I'd like to see an example of your variable names. I don't use hungarian notation and my name are usually under 10 characters.
I'd like to see an example of where using 10 levels of indentation is good. I'll bet that it's not easy to test.
I partially think you're right. Although I have the same problem with long lines that have multiple levels of parens.
I don't really have this issue. The few seconds a day that I waste formatting code are nothing near the time I waste on YouTube :-)
I would actually like to see tools changed to make this better. Maybe similar to the way unified diff shows a few lines of context.
Sure I guess. I am typing this on my EEE 900 which won't like much more than 90 chars. But even at work I put multiple 80 char wide windows side by side.
Agreed. Use Vim with 80 characters and you will rock out code like never before. I hear Emacs is good too. What are you currently using.
7) Python is designed to be written more like English than other programming languages.
That's news to me. On another note when we hire new developers I often hear this argument. Once they start coding in Python and using good OO/TDD techniques they realize that it really doesn't matter. Out of curiosity how much Python coding do you do? -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek

On Tue, May 19, 2009 at 10:45 AM, MRAB <google@mrabarnett.plus.com> wrote:
You can't always control the names you're working with. In our case, we're writing .NET-based code that uses a lot types originally defined in C#. The standard in C#-land tends to be much more verbose than in Python, and definitely presents some challenges when trying to keep lines under 80 chars. I imagine that Jython code has a similar issue when interoperating with Java. -- Curt Hagenlocher curt@hagenlocher.org

While aesthetics is a highly subjective matter, good code tends to have a "paucity begets expressiveness" feeling. I.e. experienced programmers seem to have developed an intuition for finding succinct names for entities -- names that convey the underlying meaning to the onlooker at first glance. That style is accompanied by good structure with groups of usually shortish lines with meaningful empty lines in between. The result is like good minimalist prose or a poem: a consistent piece of thinking, a pause, another piece that follows naturally from the previous. Aesthetically, this style contradicts with verboseness, long lines and generally cramming things together. The latter usually convey the image of uncertainty -- i.e. the writer is only yet trying to find a way of succinct expression, feeling a bit disoriented in the domain or language and wanting to hide the lack of confidence behind verbosity and pompous style. After all, Python has zen built in, so lets walk the path of 'import this' and revere the beauty of PEP-8 :). So, personally, I'm -0 (not that my opinion matters of course, and, after all, this is classic bikeshedding) even though quite a few of the previous arguments supporting longer lines are sensible.

Curt Hagenlocher wrote:
That's true. It's also a problem for people doing Cocoa with PyObjC. But who cares? If you want to break PEP8 for your own project, there's nothing to stop you. The only thing that PEP8 is binding on is what gets checked into the cpython source, and, for obvious reasons, that doesn't interact with C#-stuff or JVM-stuff or Cocoa-stuff to any significant degree. I'm not sure what the point of this debate is. If you want to use 500 chars per line, the interpreter won't complain. If you want to say that using more than 80 chars per line would make the cpython source read better, I would have to respectfully disagree. So, what's the problem?

On Tue, May 19, 2009 at 5:53 PM, Carl Johnson <cmjohnson.mailinglist@gmail.com> wrote:
But who cares? If you want to break PEP8 for your own project, there's nothing to stop you.
True. Unless -- hypothetically -- the architect decides that all the source in the project will follow PEP-8 and you want to do an end-run around the decision because you're tired of losing five minutes every few hours as a result of working out how to reformat a block of code to best respect the 80-char limit. *wink* -- Curt Hagenlocher curt@hagenlocher.org

Curt Hagenlocher <curt@hagenlocher.org> writes:
As pointed out elsewhere in this thread, very often the superior solution is not to re-*format* the same statement to fit, but to re-*factor* the code so it's less deeply indented or does less in each statement. And that re-factoring isn't lost time; it's saved time when later readers try to understand the code. -- \ “There was a point to this story, but it has temporarily | `\ escaped the chronicler's mind.” —Douglas Adams | _o__) | Ben Finney

Curt Hagenlocher <curt@hagenlocher.org> writes:
Yes, "refactor" is a much better word than "reformat" for what I was thinking.
Well, before deciding that, be aware that it already has a fairly specific meaning in programming terminology <URL:http://www.refactoring.com/> <URL:http://en.wikipedia.org/wiki/Code_refactoring>. -- \ “I believe in making the world safe for our children, but not | `\ our children's children, because I don't think children should | _o__) be having sex.” —Jack Handey | Ben Finney

So, it seems that support for an 80 character limit is rooted in a desire to have other people program differently than they do, somehow making their programs better just because they are adhering to an arbitrary limit on horizontal text width. That seems somewhat magical. Maybe the limit should be 40 chars, then everyone will have to refactor, and line wrap, and use smaller idents (like Google does), and use more abbreviated variable names. Maybe the origin of the 80 char limit isn't an anachronism. Maybe it had nothing to do with teletypes and low resolution CRTs. Perhaps, the programming gods of old were reaching into the future with certain knowledge that they were forcing everyone to do the right thing. Who knew? Raymond

On Wed, May 20, 2009 at 1:44 PM, Raymond Hettinger <python@rcn.com> wrote:
Or we can simply interpret the N-chars bound as a soft limit and feel free to exceed it by one character or three if it makes more sense. I am certainly not breaking a line for a single extra character. George

David Robinow wrote:
It is also the maximum number of chars that one can sensibly type on US standard office paper. 8 " X 10 char/" + 1/4 inch margin on each side. (or nearly 1" margin with 12 pitch). I thought the stdlib guideline was so that people could print stdlib files.

On Thu, 21 May 2009 03:44:15 am Raymond Hettinger wrote:
Can I remind you that the 80 character limit is for the standard library, not your own personal code? Use whatever limit you like in your own personal libraries, or no limit at all. If your productivity is enhanced by writing 100-character lines, or 300 for that matter, then go right ahead. Some people find their productivity is enhanced with an 80 character limit. There's nothing "magical" about this -- we've given some reasons. 80 character lines fit comfortably in email and printed pages without wrapping, they can be viewed even on small screens without horizontal scrolling, and, yes, some people find that this constraint enhances our productivity and so we use the same limit in our own code, not just the stdlib. We're not forcing you to do the same. The 80 character limit is a lowest-common denominator. Having a 36" high-resolution monitor, or the visual acuity to read 7pt text, should not be a prerequisite for reading the stdlib. For this common code base, forcing everyone to limit line length is less of an imposition than forcing everyone to deal with long lines.
No, 40 characters would be just foolish. The cost-benefit of constraints is not linear: there is a sweet-spot, where the cost is the minimum and the benefit is the maximum, and I believe that is around 80 characters, or possibly even a little shorter: I use a soft-limit of 70 characters in my own code, but I don't force that on anyone else.
What possible relevance is the origin? Standards can change their justification over time. Commons used to exist so that the peasants would have somewhere to graze their goats. Not a lot of people have goats any more, but we still have commons, only now they're called "parks". If the character limit didn't remain relevant, we'd remove it, but it is relevant: people do print out code onto paper, people do still have poor eyesight requiring larger font sizes, or small monitors, or large monitors with four side-by-side editor windows. -- Steven D'Aprano

On Wed, May 20, 2009 at 4:02 PM, Steven D'Aprano <steve@pearwood.info>wrote:
I see part of the problem now. People perceive the PEP-8 as the way they should write all code, not just the standard library. It seems to be passed around as the be-all-end-all, but in fact it might only represent what is good for the standard library and only the standard library. Perhaps commercial code bases, or other types of code bases should not blindly subscribe to this ideal. The 80 character width limit seems like this might be a candidate for consideration of flexibility depending on some critical factors. However, having a line width *limit* seems like a uniformly good one...to say which specific character to break up the lines might depend greatly (or solely) on the tools you (or your company) use(s). As time marches forward and email editors don't wrap (mine doesn't), printers are used less (which is already happening), etc. then standards for core libraries will probably change as well. Forward thinking is important and backwards compatibility is also important. Writing code at 80 characters takes more time, but it definitely ensures that any future standard will be compatible with it (i.e. a future 100 character width standard won't be offended by 80 character wrapped lines). So, at some point, I would predict 100 will become more prudent for standard libraries in Python and then (assuming the language is still thriving after many many years) it might become 120, etc. But it will just take time. Either way, the style for coding within a non-standard library might want to be revisited much sooner. In other words, programming to a standard which is common to all people who use it means you probably must accommodate the lowest common denominator. This would not be true for anything but the standard library.
This is a minor point, but I would argue that the origin is relevant. It helps to realize what assumptions are being made about the code base, which may or may not be true anymore. In the case of a "park", it is obvious that the origin was questioned at some point, since "parks" needn't have grass anymore. (where grass=80 character limit width)

Aaron Rubin wrote:
I see part of the problem now. People perceive the PEP-8 as the way they should write all code, not just the standard library.
I think they're reasonable guidelines to follow for code that you intend to publicise, for the same reasons that they're good for the stdlib. But nobody is going to beat you up with a stick if you don't follow them to the letter.
Yes, but the relevant question remains "Do we still need it, and if so, why?", not "It's old, so it must be out of date by now, surely?" -- Greg

On Wed, 20 May 2009 17:44:54 -0700 Aaron Rubin <aaron.rubin@4dtechnology.com> wrote:
On Wed, May 20, 2009 at 4:02 PM, Steven D'Aprano <steve@pearwood.info>wrote: As time marches forward and email editors don't wrap (mine doesn't),
That makes your mail editor a throwback. Used to be, none of them wrapped. Then an 800 lb gorilla of a company decided to ignore what the RFCs said, and made their mailer act like there WP products and wrap text. It's hard to find a modern mailer that doesn't wrap.
printers are used less (which is already happening), etc. then standards for core libraries will probably change as well.
But PDAs and Netbooks are being used more and more.
Um, I'd say it holds for pretty much every other open source project done in Python, excepting those that are targeted for some specific platform. I.e. - if you're writing scripts for a high-end CAD program, then you get one set of assumptions about the working environment. But if you're developing on and for N60, you get a completely different set. The problem is that on it's good days, this is a bikeshed issue. On it's bad day out and out religious. Choosing to follow PEP-8 so as to not waste time discussing it is a rational choice for any group working in Python. It's certainly better than no standards at all! <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On Wed, May 20, 2009 at 6:30 PM, Mike Meyer <mwm@mired.org> wrote:
I use gmail.
You can't possibly make a case that programming on either of these devices should be what we should cater to. I want to program on my Palm phone as well, but I have to accept that the world won't try to accommodate me, but the other way around.
I am trying to discern between a code base which must cater to all, and a code base which mustn't. An open source project is akin to a widely used closed source project. What they share is they don't need to cater to *the* least common denominator, but instead *a* least common denominator, which gives them more flexibility.
But choosing to pinpoint particular aspects which do not appear to make much sense and attempt to further understand the rationale behind it, so as to assess whether it is worth it to follow those aspects is very worthwhile. Whether the entire community accepts it is another thing. The entire community appears to be quite divided on this issue and rightfully so...we appear to be in the middle of change :) Otherwise, there wouldn't be so much debate on the topic.

On Wed, May 20, 2009 at 9:55 PM, Aaron Rubin <aaron.rubin@4dtechnology.com> wrote:
I like programming on my EEE. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek

On Wed, May 20, 2009 at 10:32 PM, Aaron Rubin <aaron.rubin@4dtechnology.com> wrote:
I don't think I'm expecting to be catered to because of the netbook. To me 80 just works well and is in the current PEP. So I'm happy. I just think that the people that say using 80 characters takes more time is using a very crappy editor. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek

On Wed, 20 May 2009 18:55:11 -0700 Aaron Rubin <aaron.rubin@4dtechnology.com> wrote:
Nope, you don't make things more difficult for everybody else just to make things easier for them. On the other hand, you can't possibly disenfranchise them, either - which means that a change that makes things harder on people using them needs to benefit everyone else enough to make up for it.
But the PSL is just another open source project. It has no requirement to cater to all, or to *the* lcd, any more than any other such project. In fact, it clearly doesn't, as it certainly never catered to people working in the Python implementation for the old Palm series III devices, or the N60 implementation, etc.
Oh? Doesn't seem to be much different than last time (I saw it, anyway - it may have happened again during a hiatus). Lots of people with strong personal preferences, but the best real reason around is "we've always done it that way". Of course, everyone also seems to be forgetting one of the most important points in the PEP: But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask! But why not help things along even further, by cutting the length of what's probably the most common variable name in python by 50%, and replace "self" with "my". We can't shorten cls, but we can bring it into the same part of speach by making it "our". <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Aaron Rubin <aaron.rubin@4dtechnology.com> writes:
Perhaps. Or perhaps those style constraints were chosen for the standard library *because* they're widely applicable and make sense for Python code in general.
Indeed. Such forward thinking must take into account that devices with smaller and smaller displays are being used for viewing documents, including code.
You assume that human eyesight and capacity to comprehend complex syntax will also scale with the display resolution. That doesn't seem a well-supported assumption. I think average human ability to perceive lines of text, having remained pretty much constant over the history of computing so far, will tend to remain fairly constant for the foreseeable future, and hence the 80-column limit will continue to be a good standard for Python code. -- \ “Are you thinking what I'm thinking, Pinky?” “Uh... yeah, | `\ Brain, but where are we going to find rubber pants our size?” | _o__) —_Pinky and The Brain_ | Ben Finney

For what it's worth, I'm in favour of sticking with the current 80 character limit. It's really not hard to work with or accommodate. In my workplace, I go much wider, but we all have standard environments and it's no big deal. 80 characters looks narrow to me, but I can adjust, and it makes sense to use this as a common denominator for a widely-shared piece of code like the Python core libraries. As everyone has said, it works well in emails, funny terminals, vi, emacs, IDEs, can be easily used side-by-side with other open editors, etc. These 'special cases' seem very remote until you are suddenly confronted by them. For me, the most common is when telnetting / sshing into a foreign machine which assumes an 80-character width and the terminal emulation setting is a bit mucked up, so all of a sudden you can't resize to make use of your screen real estate. Trying to read code over such a link, or through a funny email client which wraps long lines, is awful and I'm happy to accommodate those people. Working with the 80-character limit is really easy in my editor, and it's certainly much easier to fit in with the existing style of a shared codebase than to have idiosyncrasies within sections that have been edited here and there. I don't think the 80-character limit in PEP-8 is doing many people a great deal of harm. Cheers, -T

I don't think the 80-character limit in PEP-8 is doing many people a great deal of harm.
FWIW, I posted two recurring examples of where it is awkward in normal python programming. One, raising exceptions with messages -- the message doesn't typically start until 30th column or so. Two, in unittests using self.assertRaises(SomeException, expr), the expr part doesn't typically start until the 35th column or so. Also, there is a problem with indented multiline string literals where the indentation is taking up space that will never be shown to the end-user. Indented comments and in-line comments are also space challenged. I think the Google example is instructive. Their two space tabs are not a natural preference for anyone I know. Instead, it is an accommodation born from trying to fit nested, indented code into 80 columns. I'm pretty much in agreement with the OP that going to 90 or 100 columns is a better solution. Of course, if Hollerith punch cards come back into vogue, then the OP's proposal won't work out so well ;-) Raymond

"Raymond Hettinger" <python@rcn.com> writes:
As was covered earlier in the thread, cases like that are why the following style makes sense for call parameters:: def error_emitter(): raise some.name.space.LongDescriptiveError( "Message for the error" " which can cross multiple lines if necessary", other, args)
Two, in unittests using self.assertRaises(SomeException, expr), the expr part doesn't typically start until the 35th column or so.
class FrobnicationTest(unittest.TestCase): def test_frobnicates_the_spangle(self): self.assertRaises( SomeException, expr) So neither of these use cases is materially harmed by an 80-column limit.
Given the available options for making code fit nicely within 80-column lines and 4-column indentation levels, and the benefits to be had from doing so, I don't agree with your position. -- \ “Never express yourself more clearly than you are able to | `\ think.” —Niels Bohr | _o__) | Ben Finney

On 20May2009 20:16, Raymond Hettinger <python@rcn.com> wrote:
I think the Google example is instructive. Their two space tabs are not a natural preference for anyone I know.
I regret to inform you that two space tabs are my preferred indentation. -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ To be positive: To be mistaken at the top of one's voice. Ambrose Bierce (1842-1914), U.S. author. The Devil's Dictionary (1881-1906).

Le Thu, 21 May 2009 12:41:20 +1000, Ben Finney <ben+python@benfinney.id.au> s'exprima ainsi:
You are certainly right here, but this applies to "busy" line-width, which is most often < 50 chars (left-side spacing excluded), even when overall line width is > 80. Breaking lines that sensibly mirror the semantics and hold less than 50 content characters, only because of an arbitrary right-side limit, prevents confortable reading. Also, most wider lines go over the limit because they contain long literals (strings, lists) which are not complex conceptually -- they just eat horizontal space. Breaking the line in such cases hinders human parsing, it does not help it. To sum up, the human parsing factor rather requires intelligently relaxing limits, not the contrary. Denis ------ la vita e estrany ------ la vita e estrany

If the character limit didn't remain relevant, we'd remove it,
My suggestion is to just bump it up a bit (perhaps to 100 chars). Docstrings and code for method definitions in Python typically start at two tabs deep. That means that most of the body of a program is in a somewhat narrow band. This most troublesome with string literals embedded in the code and with trailing comments. IMO, if a string literal is less than 80 chars, then cutting it midstring is an anti-pattern. Breaking the literals is awkward and uncomfortable. This seems to come-up often with error messages which seem to usually be defined several levels deep so that there isn't much space left for the message. class X: def Y(self): 'Comment' for something in Z: if somecondition: raise Exception(some_message % somevalue) Another problematic area is with unittests: class TestX(unittest.testcase): def test_z(self): self.assertRaises(TypeError, real_code_starts_here) Both of those situations seem to lead to awkward line wrapping right in the middle of a literal or expression. It both cases, the literal or expression of interest starts without a whole lot of room left. Sometimes we're able to fit it in gracefully, sometimes not.
people do print out code onto paper
My experience with printing code is that vertical space is the main challenge. The unittest module for example takes at least 25 pages depending on how much you're willing to give-up margins and large type.
Some people find their productivity is enhanced with an 80 character limit.
Perhaps this is true, though I've not heard one jot of evidence to support it and certainly no evidence focusing on Python coding practices which are affected by the use of whitespace for control flow. Nor have I seen evidence of comparative productivity of 80 char limits versus 100 char limits. All we have is anecdotal evidence and personal tastes. What I have seen is a company where all of the Python programmers routinely moved into the 100 character range when necessary and it worked out fine. Also, I've seen plenty of code be made "pep-8 compliant" and not look any better for the effort. Raymond

Raymond Hettinger wrote:
My suggestion is to just bump it up a bit (perhaps to 100 chars).
If there's anything I'd suggest changing, it would be to reduce the recommended indentation from 4 chars to 2. That's what I use internally for my own code, and it seems to be a good compromise between readability and eating up too much width with indentation. -- Greg

Le Wed, 20 May 2009 18:02:54 -0700, "Raymond Hettinger" <python@rcn.com> s'exprima ainsi:
If the character limit didn't remain relevant, we'd remove it,
(to Steven) We definitely don't live in the same world ;-) In mine, any purely legacy trait change raises religious wars. People fighting against change _always_ find "good" reasons. That seems to be part of human nature (in the world I live in).
We could differenciate between overall line width and "busy" line width (from fist non-white). The latter may have a (recommanded) limit less than 80 characters. It should not be too wide for human overall comprehension (but optimum may vary greatly). Except for literals and probably some other issue (e.g. imported names*). About the former, we probably could define algorithms that nicely reformat code in a sensible manner, for printing or whatever physical constraint. Denis (*) Someone suggested to "import ... as ..." but in many cases it's wrong because other programmers cannot rely anymore on their knowledge of libraries. ------ la vita e estrany

spir schrieb:
And who determines if it *is* a purely legacy trait? Don't you think that these reasons may be valid when it isn't? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

There is, of course, a correct solution to this line length problem. The ideal maximum line length is dependent on how much horizontal space you've got, so the code should be automatically wrapped to your window size. That's how all other text displaying systems work, from html to word processors. It's just code that's the exception*. This would require good automatic wrapping, which is a bit more difficult for code than for English, but automatic reformatting utilities already exist. It would also require tool support, so everyone would need to use editors like emacs or something else that's programmable. Just your favorite notepad-on-steroids variant won't suffice anymore. Of course, it's only 2009 and this is all very much py-in-the-sky. (Though who knows what Python 6000 will bring...) * another exception are config files, but more and more people are writing gui config editors, which adapt to the window size, so these too are following the trend. The only backward compatible way I can think of to implement this is to tell your emacs or other programmable editor to automatically display files according to your window width, and wrap them to 80/whatever cpl in the on disk representation when you save. And add some magic so it only changes those parts of the file in the on disk representation that you actually edited, deal smartly with line numbering, etc, etc. Jan

Jan Kanis <jan.kanis@phil.uu.nl> writes:
It's also dependent on how different line lengths affect ease of rapid comprehension. As mentioned many times in this thread.
so the code should be automatically wrapped to your window size.
No, since that fails to account for the dependency I mention above. -- \ “Science is a way of trying not to fool yourself. The first | `\ principle is that you must not fool yourself, and you are the | _o__) easiest person to fool.” —Richard P. Feynman, 1964 | Ben Finney

OK. Again, this thread appears dead to the OP, since it has been delving into subjectiveness for quite a while now. If anybody has more objective arguments to propose, I would love to hear them. If not, then hopefully someone will read this thread and pick out the objective points for future consideration of this highly debated point. Remember that if Python is to remain a choice for future generations, its ability to be dynamic needs to remain. Times change, tools change. Languages must change as well. Making Python a hospitable environment for future generations to contribute will be important. This is what made my choice of Python 10 years ago an easy choice. Let's not forget to be dynamic so that others will make the same choice down the road. - Aaron On Fri, May 22, 2009 at 3:43 PM, Ben Finney <ben+python@benfinney.id.au<ben%2Bpython@benfinney.id.au>
wrote:

On Mon, 25 May 2009 12:35:18 -0700 Aaron Rubin <aaron.rubin@4dtechnology.com> wrote:
OK. Again, this thread appears dead to the OP, since it has been delving into subjectiveness for quite a while now.
Always a problem on those pesky interwebs :-).
And this is another example of topic drift. The OP wasn't suggesting a change to Python, so a claim that it must change is pretty clearly off topic. One thing that those espousing such a change keep forgetting is that the 79 character limit (it's not 80 - go read the PEP) isn't part of the language. It's part of a style guideline that describes what the community feels is a good style. Nothing actually forces anyone to follow it. The standard library includes code that violates the PEP, even in the public APIs (though the PEP-conforming variants have been made available recently). If you disagree with PEP 8, you're free to ignore all or part of it in your code. That won't keep the code out of the standard library if it's otherwise worthy and still readable. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

On May 25, 2009, at 13:35 PM, Aaron Rubin wrote:
Personally, I would consider "objective arguments" to be controlled, repeatasble, studies with quantitative results. I've seen such studies about light-background-dark-foreground vs. dark-foreground- light-background, which is why I use the former now. I haven't seen such studies about line width, especially not with Python text as opposed to English text. I will therefore spare you my personal, subjective opinion about this topic. Regards, Zooko

On Tue, May 26, 2009, Zooko Wilcox-O'Hearn wrote:
Personally, I would be amazed to see any significant difference between the two foreground/background combinations you list. ;-) -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "In many ways, it's a dull language, borrowing solid old concepts from many other languages & styles: boring syntax, unsurprising semantics, few automatic coercions, etc etc. But that's one of the things I like about it." --Tim Peters on Python, 16 Sep 1993

On Tue, May 26, 2009 at 09:47:05AM -0700, Aahz wrote:
Entirely off topic by now, but these differences are more significant for e.g. dyslectic people. And these studies exist and are the reason exam papers in the UK are printed black on yellow etc. To be more no-topic, for as long as I've knowingly used computers my text editor window (and thus programming environment) has been 40x80 (emacs for me ;-)). Also having code no longer then 80 chars is nice when debugging on (serial) consoles, which does happen unfortunately. You're not always in your comfy development environment. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

On Tue, May 26, 2009, Floris Bruynooghe wrote:
In case it wasn't clear, Zooko gave exactly the same color combo for foreground/background, only reversed in ordering. It was a jest at his expense for the typo. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "In many ways, it's a dull language, borrowing solid old concepts from many other languages & styles: boring syntax, unsurprising semantics, few automatic coercions, etc etc. But that's one of the things I like about it." --Tim Peters on Python, 16 Sep 1993

On 2009-05-26 18:12, Aahz wrote:
Floris is obviously using a dark-foreground-light-background color scheme, or he wouldn't have misread that. :-) -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
participants (33)
-
Aahz
-
Aaron Rubin
-
Arnaud Delobelle
-
Ben Finney
-
Cameron Simpson
-
Carl Johnson
-
Cesare Di Mauro
-
Curt Hagenlocher
-
David Robinow
-
David Stanek
-
Floris Bruynooghe
-
Georg Brandl
-
George Sakkis
-
Gerald Britton
-
Greg Ewing
-
Jan Kanis
-
Jason Orendorff
-
Jeremiah Dodds
-
Jim Jewett
-
Leonardo Santagada
-
Lie Ryan
-
Mart Sõmermaa
-
Mike Meyer
-
MRAB
-
Raymond Hettinger
-
Robert Kern
-
Ron Adam
-
spir
-
Stephen J. Turnbull
-
Steven D'Aprano
-
Tennessee Leeuwenburg
-
Terry Reedy
-
Zooko Wilcox-O'Hearn