j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
Le Wed, 20 May 2009 18:02:54 -0700, "Raymond Hettinger" firstname.lastname@example.org 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.
la vita e estrany