Aaron Rubin <aaron.rubin@4dtechnology.com> writes:
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. Or perhaps those style constraints were chosen for the standard library *because* they're widely applicable and make sense for Python code in general.
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.
Indeed. Such forward thinking must take into account that devices with smaller and smaller displays are being used for viewing documents, including code.
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.
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