Python and PEP8 - Recommendations on breaking up long lines?

[Ben Finney]

Victor Hooi <victorhooi at gmail.com> writes:

> I'm running pep8 across my code, and getting warnings about my long
> lines (> 80 characters).

Great! Thank you for working to make your code readable by keeping lines
reasonably short.

> I'm wonder what's the recommended way to handle the below cases, and
> fit under 80 characters.

In general, I advise:

* Avoid line-end backslashes like the plague. Sometimes they're
  necessary, but try very hard to write code that doesn't need them.

* Break a long line on existing open-parenthesis syntax (whether parens,
  brackets, braces, triple-quotes); early in the line is better, so the
  reader doesn't need to scan a long way back to the next line.

* Ignore the code on the first line for aligning, and instead indent
  continuation lines to a consistent level (i.e. don't line up with
  some arbitrary character on the first line).

* Use eight-column indentation for continuation lines (to clearly
  distinguish from four-column block indentation).

> First example - multiple context handlers:

I haven't used multiples in the same statement yet, and I'm annoyed that
they simultaneously encourage long statements, and have no obvious way
to break on an open parenthesis syntax.

>     with open(self.full_path, 'r') as input, open(self.output_csv, 'ab') as output:

So in this case I don't see a way to avoid the ugly line-end backslash::

    with \
            open(self.full_path, 'r') as input, \
            open(self.output_csv, 'ab') as output:

Or::

    with open(self.full_path, 'r') as input, \
            open(self.output_csv, 'ab') as output:

Both look terrible to me. I'd love to know of a way to avoid
backslashes, while still breaking the line at the comma.

> Second example - long error messages:
>
>     self.logger.error('Unable to open input or output file - %s. Please check you have sufficient permissions and the file and parent directory exist.' % e)

Break at the first open-paren. Use implicit string literal continuation
to break that literal across multiple lines inside the parens. Like so::

    self.logger.error(
            'Unable to open input or output file - %s.'
            ' Please check you have sufficient permissions'
            ' and the file and parent directory exist.'
            % e)

Also, with such a large literal this is an ideal example of why named
parameters are preferable::

    self.logger.error(
            'Unable to open input or output file - {error}.'
            ' Please check you have sufficient permissions'
            ' and the file and parent directory exist.'.format(
                error=e))

> Third example - long comments:
>
>     """ NB - We can't use Psycopg2's parametised statements here, as
>     that automatically wraps everything in single quotes.
>     So s3://my_bucket/my_file.csv.gz would become s3://'my_bucket'/'my_file.csv.gz'.
>     Hence, we use Python's normal string formating - this could
>     potentially exposes us to SQL injection attacks via the config.yaml
>     file.
>     I'm not aware of any easy ways around this currently though - I'm
>     open to suggestions though.
>     See
>     http://stackoverflow.com/questions/9354392/psycopg2-cursor-execute-with-sql-query-parameter-causes-syntax-error
>     for further information. """

That's not syntactically a comment, and I don't think pretending
triple-quoted strings are comments is good practice. If nothing else,
you'll need a special case if you want to enclose something with
existing triple-quotes.

Better to use the standard Python comment style::

    # NB - We can't use Psycopg2's parametised statements here, as
    # that automatically wraps everything in single quotes.
    # So s3://my_bucket/my_file.csv.gz would become s3://'my_bucket'/'my_file.csv.gz'.
    # Hence, we use Python's normal string formating - this could
    # potentially exposes us to SQL injection attacks via the config.yaml
    # file.
    # I'm not aware of any easy ways around this currently though - I'm
    # open to suggestions though.
    # See
    # http://stackoverflow.com/questions/9354392/psycopg2-cursor-execute-with-sql-query-parameter-causes-syntax-error
    # for further information.

which most programmer's text editors can do for you easily by applying
or un-applying comments to a whole selected region of lines with a
single command.

The comments then are correctly identified as comments by all your
programming tools, and you don't have to think about using a different
comment style depending on the content — the same style is used for all
comments.

> Also, how would I split up the long URLs? Breaking it up makes it
> annoying to use the URL. Thoughts?

I'd try very hard to find an equivalent URL that isn't so long :-) but
URLs in comments are a good example of a PEP 8 exception: if the line is
over 80 characters because it contains a long URL in a comment, that's
fine, as I'm not expecting the human reader to be scanning it carefully
like other text in the code.

-- 
 \        “I fly Air Bizarre. You buy a combination one-way round-trip |
  `\    ticket. Leave any Monday, and they bring you back the previous |
_o__)     Friday. That way you still have the weekend.” —Steven Wright |
Ben Finney