David Stanek wrote:

I'll bite.

On Tue, May 19, 2009 at 12:43 PM, Aaron Rubin wrote:

...

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.

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.

If there are too many lines or too much indentation then it's time to move some of the code into a function.

...

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?

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.

[snip] IMHO, the names should be long enough to be meaningful but not too long.

On Tue, May 19, 2009 at 10:14 AM, David Stanek wrote:

I'll bite.

On Tue, May 19, 2009 at 12:43 PM, Aaron Rubin wrote:

...

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.

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.

See below for code example

...

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?

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 gave an example already in the snippet you quoted.

...

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?)

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.

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.

...

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.

I partially think you're right. Although I have the same problem with long lines that have multiple levels of parens.

...

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.

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 :-)

or responding to people's posts about character width issues ;)

...

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)

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.

...

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.

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.

...

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.

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.

Wing IDE.

...

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?

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)

-- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek

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).

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

Aaron Rubin writes:

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:

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.

On Tue, May 19, 2009 at 10:45 AM, MRAB wrote:

...

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.

IMHO, the names should be long enough to be meaningful but not too long.

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

On Tue, May 19, 2009 at 1:15 PM, Raymond Hettinger 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

On Wed, 20 May 2009 03:53:33 am Aaron Rubin wrote:

On Tue, May 19, 2009 at 10:14 AM, David Stanek wrote:

...

...

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).

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:

...

...

import math isinstance(math, type(math)) True

...

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.

See below for code example

Namely:

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.

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.

...

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 gave an example already in the snippet you quoted.

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.

...

...

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.

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

Jason Orendorff writes:

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')] [and so on]

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

On Tue, May 19, 2009 at 5:53 PM, Carl Johnson 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 writes:

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.

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 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

Le Wed, 20 May 2009 11:38:55 +0900, "Stephen J. Turnbull" s'exprima ainsi:

...

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.

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

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

Le Wed, 20 May 2009 19:40:31 +1000, Ben Finney s'exprima ainsi:

spir writes:

...

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) )

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))

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 writes:

Ben Finney s'exprima ainsi:

...

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))

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

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?

This can be a bit improved (again, to my eyes) using ~ double indentation for continuation lines ~ closing sings (parens, etc) on their own line

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 at 5:40 AM, Ben Finney wrote:

spir writes:

...

            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) )

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 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

...

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.

Yes, "refactor" is a much better word than "reformat" for what I was thinking.

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 wrote:

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. Actually, 80 is the number of columns in a Hollerith card. It would be totally stupid to write code that couldn't be punched!

On Thu, 21 May 2009 03:44:15 am Raymond Hettinger wrote:

...

...

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.

Yes, "refactor" is a much better word than "reformat" for what I was thinking.

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.

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.

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.

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.

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.

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

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

David Robinow writes:

Actually, 80 is the number of columns in a Hollerith card. It would be totally stupid to write code that couldn't be punched!

That's right. After all, punching the author of the code will get you locked up, no matter how richly he deserves it!

On Wed, May 20, 2009 at 6:30 PM, Mike Meyer wrote:

On Wed, 20 May 2009 17:44:54 -0700 Aaron Rubin wrote:

...

On Wed, May 20, 2009 at 4:02 PM, Steven D'Aprano

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.

I use gmail.

...

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.

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.

...

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.

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.

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.

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!

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.

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 7:25 PM, David Stanek wrote:

On Wed, May 20, 2009 at 9:55 PM, Aaron Rubin wrote:

...

On Wed, May 20, 2009 at 6:30 PM, Mike Meyer wrote:

...

On Wed, 20 May 2009 17:44:54 -0700 Aaron Rubin wrote:

...

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.

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 like programming on my EEE.

I have an EEE as well. But I don't expect the community to cater to me.

-- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek

On Wed, 20 May 2009 18:55:11 -0700 Aaron Rubin wrote:

...

...

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. 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.

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.

...

...

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. 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. 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 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.

...

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! 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.

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". 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

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

"Raymond Hettinger" writes:

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.

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.

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.

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

Le Wed, 20 May 2009 18:02:54 -0700, "Raymond Hettinger" 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).

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.

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

Le Thu, 21 May 2009 02:22:19 +0100, MRAB s'exprima ainsi:

...

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.

I find an indentation of 4 characters to be a good compromise in a language like Python where indentation is important.

I do, too. 3 is the very minimum for my eyes to vertically parse code structure. 2 is definitely too narrow for me, even with rather short blocks. Denis ------ la vita e estrany

On Thu, May 21, 2009 at 9:04 AM, Lie Ryan wrote:

Raymond Hettinger wrote:

...

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.

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.

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 writes:

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.

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

Jeremiah Dodds wrote:

On Thu, May 21, 2009 at 9:04 AM, Lie Ryan mailto:lie.1296@gmail.com> wrote:

Raymond Hettinger wrote:

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.

[clipped]

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.

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]

This is how I will write program if we have 160 character limit:

def foo(f, a, b, c): return [[((f(x, y) * i, i) if i % 2 else 0) for i, x in enumerate(a) if f(y, x) == a + x] for y in [c(z) for z in range(a, a * b + c, c)]]

except there will be no line breaks...

I love list comprehension so much that I often _unconsciously_ write a very complex list comprehensions. 80-character convention acts as a reminder to consider refactoring.

that makes sense to because your example starts close to the left margin. What I'm more concerned about is lines that start many tabs deep. Those become awkward, causing you to wrap them differently than if they were not tabbed. So, I think the 80 char limit should be relaxed only when there is a bunch of whitespace to the left. Your cues for refactoring and coding style should not depend on the initial level of indentation. Raymond

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 wrote:

[Lie Ryan]

...

This is how I will write program if we have 160 character limit:

def foo(f, a, b, c): return [[((f(x, y) * i, i) if i % 2 else 0) for i, x in enumerate(a) if f(y, x) == a + x] for y in [c(z) for z in range(a, a * b + c, c)]]

except there will be no line breaks...

I love list comprehension so much that I often _unconsciously_ write a very complex list comprehensions. 80-character convention acts as a reminder to consider refactoring.

that makes sense to because your example starts close to the left margin. What I'm more concerned about is lines that start many tabs deep. Those become awkward, causing you to wrap them differently than if they were not tabbed. So, I think the 80 char limit should be relaxed only when there is a bunch of whitespace to the left. Your cues for refactoring and coding style should not depend on the initial level of indentation.

Raymond

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

[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 5/19/09, Jason Orendorff wrote:

On Tue, May 19, 2009 at 1:15 PM, Raymond Hettinger wrote: I find the long lines in my code are not as contrived as the thread so far suggests:

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.

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")

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 5/21/09, Raymond Hettinger wrote:

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.

Level of indentation is itself one of the strongest cues. I will agree that (ideally) it should not affect the strength of *other* cues. -jJ

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

Jim Jewett schrieb:

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.

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.

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

wrote:

Jan Kanis writes:

...

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

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

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

On May 25, 2009, at 13:35 PM, Aaron Rubin wrote:

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.

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 Wed, 27 May 2009 02:47:05 am Aahz wrote:

On Tue, May 26, 2009, Zooko Wilcox-O'Hearn 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.

Personally, I would be amazed to see any significant difference between the two foreground/background combinations you list. ;-)

Well, if you put the foreground *behind* the background, you can't see it at all unless you turn the monitor around, and then all the letters are reversed. -- Steven D'Aprano

On Tue, May 26, 2009, Floris Bruynooghe wrote:

On Tue, May 26, 2009 at 09:47:05AM -0700, Aahz wrote:

...

On Tue, May 26, 2009, Zooko Wilcox-O'Hearn 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.

Personally, I would be amazed to see any significant difference between the two foreground/background combinations you list. ;-)

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.

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 Tue, May 26, 2009 at 06:56:30PM -0500, Robert Kern wrote:

On 2009-05-26 18:12, Aahz wrote:

...

On Tue, May 26, 2009, Floris Bruynooghe wrote:

...

On Tue, May 26, 2009 at 09:47:05AM -0700, Aahz 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. Personally, I would be amazed to see any significant difference between

On Tue, May 26, 2009, Zooko Wilcox-O'Hearn wrote: the two foreground/background combinations you list. ;-) 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.

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.

Floris is obviously using a dark-foreground-light-background color scheme, or he wouldn't have misread that. :-)

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