About the 79 character line recommendation

[John Machin]

Steve Bergman wrote:
[snip]
> However, I am finding that the 79 character line prescription is not
> optimal for readability.
>
> Certainly, cutting back from the length of lines that I used to use has
> *helped* readability.  But if I triy very hard to apply 79, I think
> readability suffers.  If this were just something that was an issue
> occasionally, I would just put it off to "know when to break the
> rules".  However, find myself going to 90 to 100 characters very
> frequently.  Now, if it were just me, I'd shoot for < 100.  However,
> the Python philosophy includes making code easier for others to read,
> as well.
>

Are you taking advantage of all the various options for line
continuation besides \ that exist in Python, like (a) automatic
concatenation of adjacent string literals (b) automatic continuation
until () [] or {} are balanced? Example using both:

            fprintf(self.logfile,
                "WARNING *** Conflict between "
                "std format code %d and its format string %r\n",
                fmtcode, unistrg)

Aside: In this most noble of languages, fprintf() has a one-line
implementation:

def fprintf(f, fmt, *args):
    f.write(fmt % args)

>
> While I'm on this general topic, the guide mentions a pet peeve about
> inserting more than one space to line up the "=" in assignment
> statements.  To me, lining them up, even if it requires quite a few
> extra spaces, helps readability quite a bit.  Comments?

Merely aligning the = would annoy the crap out of me. However if the
RHS of a bunch of *related* assignments could be made clearer by
inserting extra space, *and* they were more complicated than the
following trivial example of what I mean, I'd do it.
        red = c & 0xff
        green = (c >> 8) & 0xff
        blue = (c >> 16) & 0xff
c.f.
        red   =  c        & 0xff
        green = (c >>  8) & 0xff
        blue  = (c >> 16) & 0xff

Cheers,
John