What PEP 8 guidelines do you ignore, and which ones do you stick to? [closed]

Answer 1

PEP8 says to avoid "More than one space around an assignment (or other) operator to align it with another" and "never use more than one space" around math operators, but I don't follow this.

I often add "extraneous whitespace" when neighboring lines are related or very similar, but not quite the same:

search_start = (f - f_1/3) * n/fs
search_stop  = (f + f_1/3) * n/fs

 

b_lpf, a_lpf = filter(N, 2*pi*fc, 'low',  analog=True)
b_hpf, a_hpf = filter(N, 2*pi*fc, 'high', analog=True)

 

p[x >  1] =                         np.cosh(order * np.arccosh( x[x >  1]))
p[x < -1] = (1 - 2 * (order % 2)) * np.cosh(order * np.arccosh(-x[x < -1]))

 

b0 =  (1 + cos(w0))/2
b1 = -(1 + cos(w0))

---

Similarly, it's annoying that I get code style warnings for arrays of numbers formatted in the readable way that they are normally formatted by the library itself:

a = array([[-0.198,  0.248, -1.17 , -0.629,  1.378],
           [-1.315,  0.947, -0.736, -1.388,  0.389],
           [ 0.241, -0.98 ,  0.535,  0.951,  1.143],
           [-0.601,  1.286, -0.947,  0.037, -0.864],
           [ 0.178, -0.289, -1.037, -1.453, -0.369]])

This produces a bunch of E201 E202 E222 violations.

PEP8 would rather have it formatted it like this, apparently, because we can't ever have extra whitespace before commas or after brackets, even if it improves readability:

a = array([[-0.198, 0.248, -1.17, -0.629, 1.378],
           [-1.315, 0.947, -0.736, -1.388, 0.389],
           [0.241, -0.98, 0.535, 0.951, 1.143],
           [-0.601, 1.286, -0.947, 0.037, -0.864],
           [0.178, -0.289, -1.037, -1.453, -0.369]])

Answer 2

My company's style guidelines specifically call for tabs, not spaces. PEP 8 hints that spaces are preferable but we've found the opposite. I like to see code indented 4 'spaces' in VIM, a coworker prefers 8 'spaces' in Emacs. Using tabs lets us both set our editors to show the code as we prefer it.

Note that in other C-based languages, indentation is in fact merely formatting but in Python indentation is syntax, thus we feel that indentation level 2 should be represented by 2 of something (i.e. tabs) not 4 or 8 of something (i.e. spaces).

Indentation character selection is probably the original holy flame war (even before the VIM / Emacs flamewars) so I do expected to be modded to oblivion for expressing an opinion on the subject!

Answer 3

PEP8 says

Note that most importantly, the """ that ends a multiline docstring should be on a line by itself, and preferably preceded by a blank line, e.g.:

"""Return a foobang

Optional plotz says to frobnicate the bizbaz first.

"""

I find this rather bizarre, since it's just "extraneous whitespace" and treats opening quotations differently from closing quotations for no obvious reason.

A rationale is given is in PEP 257:

The BDFL recommends inserting a blank line between the last paragraph in a multi-line docstring and its closing quotes, placing the closing quotes on a line by themselves. This way, Emacs' fill-paragraph command can be used on it.

Emacs, really? Everyone should do weird things to cater to the idiosyncrasies of a particular command in a particular editing tool?

I also think it's weird to put the beginning of the docstring on the same line as the quotes (not required, but recommended), while insisting that the closing quotations be on their own line. I think this is more logical, and should be used for both single line and multi-line docstrings:

def foobang(bizbaz, plotz=None):
    """
    Return a foobang

    Optional plotz says to frobnicate the bizbaz first.
    """

    if plotz is not None:
        ...

Update: The bold part has been removed and now it just says to "place the closing quotes on a line by themselves", and that the "summary line may be on the same line as the opening quotes or on the next line".

Answer 4

The "problem" with PEP 8 is that it treads on areas of personal preference that are subject to quite high amounts of emotion for most programmers.

For me personally, camelCase vs underscores and column alignment directives were constant issues. I also see point in lots of other responses here and sometimes I break PEP 8 intentionally because in that particular case it just "makes sense".

There was a point in my Python programming career when I simply gave up and turned to (using) PEP 8. It was relatively easy for most items, so nowadays the only major issue I still have is the column alignment. That one's just too messy to obey(though I hatefully do anyway). Anyway, as a result of my "giving up", my code is now much more readable to my colleagues - and - surprisingly: even to me (except for the column alignment thingy :p ).

I must also recognize what PEP 8 has done for python itself: between 2.x (non-compliant) and 3.x (compliant), I find it much easier to "always know" what a particular function's name will be. Python's "batteries" are sorted much nicer now.

Answer 5

The "79 characters per line" part is nonsense. Their very own example shows how unreadable code becomes when doing this:

class Rectangle(Blob):

    def __init__(self, width, height,
                 color='black', emphasis=None, highlight=0):
        if width == 0 and height == 0 and \
           color == 'red' and emphasis == 'strong' or \
           highlight > 100:
            raise ValueError("sorry, you lose")
        if width == 0 and height == 0 and (color == 'red' or
                                           emphasis is None):
            raise ValueError("I don't think so -- values are %s, %s" %
                             (width, height))
        Blob.__init__(self, width, height,
                      color, emphasis, highlight)

It's like try-
ing to read
a news arti-
cle written
like this.

80-column terminals havn't been a serious development environment for over a decade. When I do need to edit from a crippled 80x25 environment in a pinch, editor wrapping is a minor inconvenience; I'm not going to maim my code during normal development just to avoid that.

120 column wrapping is perfectly sensible for modern development, and I have no problem with 140. This guideline is obsolete and following it results in ugly, hard-to-read code.

Answer 6

I don't agree with this:

- Imports should usually be on separate lines, e.g.:

    Yes: import os
         import sys

    No:  import sys, os

I always write simple imports together. I don't see any advantage to writing them all on separate lines: all it does is add bloat to the top of each source file, and turn something concise and easy to type into something that's borderline boilerplate, eg. something that's so verbose it starts to be tempting to copy and paste from other files.

This is instantly readable and understandable:

import sys, os, time, gc, inspect, math, doctest

It's short, easy to skim, and easy to add to. I do use multiple import statements if there are too many on one line, of course, or if I need a from import.

I also do generally keep standard library imports separate from imports of my own modules and other libraries, which agrees with the concept of grouping PEP8 recommends.