[Python-ideas] 80 character line width vs. something wider

spir denis.spir at free.fr
Thu May 21 09:06:55 CEST 2009


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

> 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



More information about the Python-ideas mailing list