Google Python Style Guide | Hacker News Reader

Google Python Style Guide

google-styleguide.googlecode.com

49 pointsiamelgringo23 comments

A "how this differs from PEP8" summary would be useful to me, assuming it differs.

The crucial difference:

Google (original formatting):

  BE CONSISTENT.

PEP8:

  A Foolish Consistency is the Hobgoblin of Little Minds

No...those are different. One is just telling you to "be" consistent and the other is telling you not to be "foolish" about it. Much different in my mind.

Seeing as the response is to a comment asking for differences, wouldn't it make sense to assume that it shows differences? In fact, the response notes that they are an example of a "crucial difference".

I think sigzero means "different" as in "not contradictory or in conflict"

Google uses CAPS LOCK that I understand as a command "be consistent no matter what".

The quote from PEP8 translates in my mind to "be consistent if it's worth it".

These policies are not orthogonal. You can't satisfy both in all cases.

I had thought the main difference was indenting with 2 spaces instead of 4, but this style guide says 4 spaces, too. I guess Google deliberately brought themselves in sync with the Python mainstream.

This style guide looks like a superset of PEP 8 -- where PEP 8 describes what Python code should look like, this guide goes through every Python feature and lays out exactly where a sizable group of top-notch Python hackers were willing to draw the line on maintainability vs. whipupitude for large, long-running projects.

This is decidedly not the same as the internal guide. 2-space indents are the norm, and functions_like_this are supposed to be spelled FunctionsLikeThis (yes, with the leading capital). Those are the two big differences from PEP8 that I can think of.

> Indent your code blocks with 4 spaces.

I had this notion it formerly was 2 spaces (too little, IMH-once-bitten-O). Anyone know when it changed, if it did ?

P.S. In http://groups.google.com/group/django-developers/msg/f6a86d1... , back in Aug.2008, GvR says "Most of it [Google's unpublished internal Python style] is simply PEP-8 with 2-space indents."

(I dislike 2 spaces, once bitten by missing an indentation bug. I try to stick to 80 columns - both for print and side-by-side on screen - and think that more than 4 or 5 levels of indentation is "doing it wrong".)

I've always seen python style guides requiring 4 spaces. (With exceptions for 8!)

Ruby has standardized on 2 spaces.

I've noticed in my own experience that 2 spaces is not enough to read python quickly. 2 spaces works fine in ruby because whitespace isn't significant, you can find the end of a control structure by looking for the end keyword.

It was 2 spaces indeed when I first saw these guidelines (about a month ago)

Thanks, I suppose you mean the internal Google style. Curiously, in that Django thread I linked above, the next post mentions this: http://code.google.com/p/soc/wiki/PythonStyleGuide

Which is a style guide for the "SoC framework, and Melange web applications", updated Jun.2009; it does specify 2 spaces, duly noted as a difference from PEP-8.

What's wrong with 2 spaces? I like 2 spaces.

I like them too, the problem is when you want to use (paste) some code that is not yours - you need to re-indent it.

Then use 2 spaces. To me 2 spaces squishes code to close together. I like 4 spaces so that is what I use. You can always sift your code through a code formatter if there are differing standards on whatever project you are on.

Or just use tabs, so everyone can set the display to what they like (without actually rewriting the file).

/me hides before the flames start :)

Within each grouping, imports should be sorted lexicographically, ignoring case, according to each module's full package path.

  import foo
  from foo import bar
  from foo.bar import baz
  from foo.bar import Quux
  from Foob import ar

That seems kind of time consuming...

Some text editors have a function for sorting text in-place. Vim does, and I assume Emacs does too.

Sorting makes it easier to recognize a common grouping of imports (e.g. some recurring functionality that requires three particular modules) without inspecting the words carefully.

Emacs: M-x sort-lines

> which should inherit from the built-in Exception class

I hate that. should inherit from StandardError IMNSHO. It's a quibble though and a pointless one until the standard library follows that. (which it never will...)

> Use the "implicit" false if at all possible.

Is so wrong, for the listed caveat reasons and more. It's the opposite of readability to me. Similar issues with the use default iterators. If my loop is expecting a dictionary and to iterate over it's keys I really want the "foo has no method keys" error rather than looping over a list and creating hard to discover/understand bug.

I enjoyed this bit of example code:

  x = '%s, %s!' % (imperative, expletive)

A decidedly familiar sentence structure...

I don't know if this is just me, but the page looks super ugly on Firefox.

agreed that it looks super ugly. but it's probably meant first and foremost to be internal documentation, so i doubt that the writers cared to make it all snazzy using translucent boxes with rounded corners and jquery rollover effects.

Reply on news.ycombinator.com