[Chicago] Google Python Style Guide

[Augie Fackler]

On Sep 19, 2009, at 7:09 PM, Martin Maney wrote:

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

Come at it as a C++ or Java programmer though - most projects at  
Google use Java and C++ primarily, and last I knew the majority of  
Googlers only know Python at the level of having read _Python in a  
Nutshell_ on the shuttle to work. The list comprehension is something  
that a lot of people have a little trouble with if they're coming to  
Python as an nth programming language. I'll confess I found it non- 
intuitive (and a little confusing) at first.

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

The point is that you might write a service in Python which some other  
poor sucker^W^W engineer will have to use, and if it acts oddly, he  
might need to be able to read the source. He still has to be able to  
parse your code if he's not fluent in the nuances of your language.  
The price for that is that you neuter some of the more useful features  
of the language.

Then again, my worst single piece of Python comes from abusing map,  
reduce, and list comprehensions. I think it's the single feature of  
the language which requires the most restraint.

> 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)

When you're looking at a 1000 line file (sadly, not uncommon), it's  
nice to know that the function that just got used is really an import  
from another module (because it has a foo. prefix) and that you should  
go look in another file instead of scrolling around wildly or  
searching for "def ..." looking for a function when it might be a  
class (this has happened to me even in small codebases) gets tedious.

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

Indeed!

> (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)
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> http://mail.python.org/mailman/listinfo/chicago
>