i have decided

[Skaperen]

after reading the history of where and how the line width of terminals came from (including the very interesting history of punch cards), i have decided that there is no real importance to what width is used other than who is affected by this decision, how they are affected, and how many are affected. in these days, the fast majority of people are using hardware that, though in many cases is small, has no hard limit for line width that cannot be worked around, unlike virtually all the hardware in the past. one factor, in particular, was the use by Univac of 90 columns on exactly the same physical card size that IBM had 80 columns on and started with 40 columns. many decisions were made to follow similar limitations even into the days of software emulation. today, virtually no software (such as xterm) actually has such limits. what limits do exist are the result of bad business decisions or bad design decisions.

around 1980, i had an Apple II computer (integer BASIC version). the floating point BASIC version was out but i didn't need or care for what it offered. i wanted to program in 6502 assembly. i wrote my own terminal program that supported 40 columns. i tried to squeeze in more. 80 columns was completely unreadable. 60 columns could be read, but was a horrible strain on my eyes and i didn't like it at all. 40 columns was at least half-way decent and at this size, let me use character mode on the screen. in pixel mode, i also did a 35 character width and a 31 character width which looked even better. i also tried taller characters (21,19,17,16,14 rows) and got some really nice displays that were very hard to use, whether it was one of the local BBSes or one of the mainframes at work.

i'm used to working on very limited displays (40x24, the size i most regularly used) with software that expected there to be more. so if my code ends up being wider than some display, i don't think there is much of an issue with that. IMHO, the direction of making code fit well in all displays is placing its burden only on coders and that is too much of a burden. much of my code that came before Python went beyond 80 characters and i got no (zero, nada, zilch) complaints about it. i was following the 79 character limit of PEP 8 and kept virtually all my code within. i even went down to 71.

but no more. its not for me. other aspects of PEP 8 i'll continue with, but not the limit on number of characters per line. in case you wonder, my display is 166 columns by 46 rows. and sometimes i bring up one that is 184x51. i have also figured out how to start a background detached screen display of just about any size i want.

[gruntfutuk]

... who is affected by this decision, how they are affected, and how many are affected...

I'd say that was true of most decisions.

Raymond Hettinger, amongst others, has advised not to be a slave to the PEP8 line length guidance.

For me, personally, it is about reading comfort and I don't like reading long lines of code. I would much rather they were broken down into some useful nuggets using the continue character if not on the same line.

I do tend to use full screen mode most of the time, so have plenty or screen estate available, but I do this to avoid distractions rather than to make it easier to use the full width of the screen for text.

[Gribouillis]

You could use a code beautifier such as yapf to reformat your code now and then. It has a COLUMN_LIMIT option which seems OK for this issue.

[Skaperen]

i do like to convert long print call lines and other calls to multi-line with the implied continuation of and ending comma, putting argument on a separate line. but of there a bunch of them in sequence, and only few of them need it i won't, on the basis the like-formatting of like lines (such as a run of 7 call() calls to run 7 command), has a better value of code readability.

i'm just not going to consider a line of length 100 to be loer in value. i'm going to look at it as "does the code need to be that long" instead os "does the line need to be that long". if it makes sense to shorten the code, break it into multiple statement, or eve just break it into 2 statements, i will. i will generally avoid using an arbitrarily placed backslash continuation. the __doc__ comments near the top will generally be line split before it is 71 columns, after the space at the end of a word, followed by my old style comments. that will be triple quoted so i can still avoid backslashes.