[Chicago] Google Python Style Guide

[Martin Maney]

On Sat, Sep 19, 2009 at 04:29:40PM -0500, Brian Ray wrote:
> Heh, this is really funny... it is like  super charged PEP8.

With simple yet amusing in-page widgets to "reveal details"!

Really, I came across very little that made me say "uhm, wait".  One
that comes to mind, perhaps because I'd just violated it earlier today,
was the IMO over-strict one about limiting list comprehensions.  I do
not for a moment think that

    result.extend('%s %s' % (p, s) for p in prefixes for s in tails)

would be improved in any reasonable way by unrolling it into multiple
lines, yet the rule says Only One Iterable Is Allowed.  I think they've
just chosen a 90% right condition and turned it into a too-rigid rule
that has obvious failings.  Of course, the intent - don't write overly
involved list comprehensions -  is one with which I agree.

Another issue they've made me think about is importing non-module
objects.  "from xyz import *" is easy to argue against, but I was
surprised to see the rule (1) "Use imports for packages and modules
only."  I'll concede that Google probably has more experience than I do
about large code bases with many different people working on them, but
I can't see what the problem is here, unless they're in the habit of
shuffling functions or classes about from one place to another with gay
abandon.  (I will say that the sort of thing I use from ... import
x,y,z with is mostly framework-ish stuff that gets used over and over
in some files, such as Django's Model class and field types, and that
may be partly because so many of them have long-enough names as it is)

Style guides: the biggest, most in need of painting, bikesheds ever! :-)


(1) I still find that terse, not clear.  The expansion makes it clear:
"Use import x for importing packages and modules. Use from x import y
only when x is a package and y is a module."

-- 
vi is a microcosm of the Unix world.  Don't expect
to learn all of it at once; perhaps you shouldn't expect
to learn all of it at all.  -- Jon Lasser (Think Unix)