7 ms·
Google Python Style Guide
- tvon 17y agoA "how this differs from PEP8" summary would be useful to me, assuming it differs.
- d0mine 17y agoThe crucial difference: Google (original formatting): BE CONSISTENT. PEP8: A Foolish Consistency is the Hobgoblin of Little Minds
- sigzero 17y agoNo...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.
- vcrash 17y agoSeeing 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".
- tvon 17y agoI think sigzero means "different" as in "not contradictory or in conflict"
- d0mine 16y agoGoogle 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.
- etal 17y agoI 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.
- durin42 17y agoThis 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.
- ableal 17y ago> 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/f6a86d135fb2968f 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".)
- epochwolf 17y agoI'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.
- DannoHung 17y agoWhat's wrong with 2 spaces? I like 2 spaces.
- sigzero 17y agoThen 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.
- viraptor 17y agoOr just use tabs, so everyone can set the display to what they like (without actually rewriting the file). /me hides before the flames start :)
- ntoshev 17y agoI like them too, the problem is when you want to use (paste) some code that is not yours - you need to re-indent it.
- sigzero 17y agoWithin 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...
- etal 17y agoSome 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.
- endgame 17y agoEmacs: M-x sort-lines
- njharman 17y ago> 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.
- Qz 17y agoI don't know if this is just me, but the page looks super ugly on Firefox.
- pgbovine 17y agoagreed 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.
- 1amzave 17y agoI enjoyed this bit of example code: x = '%s, %s!' % (imperative, expletive) A decidedly familiar sentence structure...