Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Terry Reedy <tjreedy@udel.edu>
Subject: Re: Python and PEP8 - Recommendations on breaking up long lines?
Date: Wed, 27 Nov 2013 21:55:08 -0500
References: <a98cfbef-bc48-41e8-98de-e616f201ffbe@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
In-Reply-To: <a98cfbef-bc48-41e8-98de-e616f201ffbe@googlegroups.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3339.1385607330.18130.python-list@python.org>
Lines: 118
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:60664

On 11/27/2013 8:57 PM, Victor Hooi wrote:

[sorry if the re-wrapping mis-formats anything]

> I'm running pep8

Ah yes, the module that turns PEP8 into the straightjacket it explicitly 
says it is not meant to be.

> across my code,

We mostly to not change existing stdlib modules to conform unless they 
are being edited anyway for fixes and features.

> and getting warnings about my long lines (> 80 characters).

You are free to ignore such


> I'm wonder what's the recommended way to handle the below cases, and
> fit under 80 characters.
>
> 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 believe () does not work, so put \ after 'input,'.

> 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?
>
> 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:

Such gluing in a documented feature and I think you can trust it to not 
disappear (for at least a decade ;-).

> 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?
>
> 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?

Either are ok.

> 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.

Blank lines are normal in triple-quoted strings and recommended for 
docstrings longer than a line. So I am puzzled as to your problem.

> Also, how would I split up the long URLs?

Don't if you can possibly avoid it.

> Breaking it up makes it annoying to use the URL.

Yep.

> Thoughts?

Some urls, especially long ones, have extra tracking/query junk that can 
be removed while still pointing to the page.


-- 
Terry Jan Reedy