Python coding standards/best practices

Question

In python do you generally use PEP 8 -- Style Guide for Python Code as your coding standards/guidelines? Are there any other formalized standards that you prefer?

Answer 1

Yes, I try to follow it as closely as possible.

I don't follow any other coding standards.

Answer 2

I follow it extremely rigorously. The only god before PEP-8 is existing code bases.

Answer 3

I follow these guidelines. I think they are exactly the same than PEP 8, but are more synthetic and based on examples.

If you are using wxPython you might also want to check these too.

Answer 4

"> In python do you generally use PEP 8 -- Style Guide for Python Code as your coding standards/guidelines? Are there any other formalized standards that you prefer?"

As mentioned by you follow PEP 8 for the main text, and PEP 257 for docstring conventions

Along with Python Style Guides, I suggest that you refer the following:

1. Code Like a Pythonista: Idiomatic Python
2. Common mistakes and Warts
3. How not to write Python code
4. Python gotcha

Answer 5

PEP 8 is good, the only thing that i wish it came down harder on was the Tabs-vs-Spaces holy war.

Basically if you are starting a project in python, you need to choose Tabs or Spaces and then shoot all offenders on sight.

Answer 6

To add to bhadra's list of idiomatic guides:

Checkout Anthony Baxter's presentation on Effective Python.

An excerpt:

# dict's setdefault method turns this:
if key in dictobj:
    dictobj[key].append(val)
else:
    dictobj[key] = [val]
# into this:
dictobj.setdfault(key,[]).append(val)

Answer 7

I stick to PEP-8 very closely.

There are three specific things that I can't be bothered to change to PEP-8.

• Avoid extraneous whitespace immediately inside parentheses, brackets or braces.

  Suggested: spam(ham[1], {eggs: 2})

  I do this anyway: spam( ham[ 1 ], { eggs: 2 } )

  Why? 30+ years of ingrained habit is snuggling ()'s up against function names or (in C) statements keywords. Starting with Fortran IV in the 70's.

• Use spaces around arithmetic operators:

  Suggested: x = x * 2 - 1

  I do this anyway: x= x * 2 - 1

  Why? Gries' The Science of Programming suggested this as a way to emphasize the connection between assignment and the variable who's state is being changed.

  It doesn't work well for multiple assignment or augmented assignment, for that I use lots of spaces.

• For function names, method names and instance variable names

  Suggested: lowercase, with words separated by underscores as necessary to improve readability.

  I do this anyway: camelCase

  Why? 20+ years of ingrained habit of camelCase, starting with Pascal in the 80's.