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 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.
(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.
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.
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.
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.
> 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.
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.