Victor Hooi <victorh...@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
--
https://mail.python.org/mailman/listinfo/python-list
