Python and PEP8 - Recommendations on breaking up long lines?

[Ned Batchelder]

On 11/27/13 8:57 PM, Victor Hooi wrote:
> Hi,
>
> I'm running pep8 across my code, and getting warnings about my long lines (> 80 characters).
>
> I'm wonder what's the recommended way to handle the below cases, and fit under 80 characters.

My recommendations usually amount to: write more statements, each 
shorter than what you have.

> First example - multiple context handlers:
>
>              with open(self.full_path, 'r') as input, open(self.output_csv, 'ab') as output:
>
> and in my case, with indents, the 80-character marks is just before the ending "as output".
>
> What's the standard recognised way to split this across multiple lines, so that I'm under 80 characters?
>
> I can't just split after the "as input," as that isn't valid syntax, and there's no convenient parentheses for me to split over.
>
> Is there a standard Pythonic way?

The important thing in a with statement is that the assigned name will 
be closed (or otherwise exited) automatically.  The open call is just 
the expression used to assign the name.  The expression there isn't 
really important.  This looks odd, but works the same as what you have:

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

(Use different names for the two parts of the "as" clauses if you like.)

>
> 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)
>
> I can use triple quotes:
>
>              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)
>
> However, that will introduce newlines in the message, which I don't want.
>
> I can use backslashes:
>
>              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)
>
> which won't introduce newlines.
>
> Or I can put them all as separate strings, and trust Python to glue them together:
>
>              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)
>
> Which way is the recommended Pythonic way?

Use the separate strings, but don't forget the spaces:

     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
     )

>
> 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. """
>
> In this case, I'm guessing a using triple quotes (""") is a better idea with multi-line comments, right?

As Ben pointed out, using an actual comment is best.

> However, I've noticed that I can't seem to put in line-breaks inside the comment without triggering a warning. For example, trying to put in another empty line in between lines 6 and 7 above causes a warning.

I don't know what you mean about line-breaks causing warnings.

--Ned.

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