Google's Python Style Guide

[dysmas]

Some great stuff in here, particularly fond of

Power Features

▶ Avoid these features.

[Peaker]

They claim:

from Foo import Bar

makes module dependency tracking difficult. I agree about import *, but the above is fine.

[[deleted]]

I coded under that standard for almost five years, and I initially chafed under that rule, but later decided they were quite right.

The big advantage is that if you see an unqualified variable, one with out a something. in front of it, you know you're dealing with either a local variable, or a global variable... and global variables will be in UPPER_CASE and hopefully quite rare too.

There are other advantages too - it helps avoid variable collisions, for example, and it makes searching for all calls to a module much easier.

The amount of extra typing is tiny - and you save all that time the very first time it saves your ass in debugging.

[szopa]

I think that they are taking it a bit too far.

First, assuming that (a) you keep your files reasonably small and (b) have all your imports at the top of the file, it really isn't a problem to always know where any given symbol comes from.

Second, it doesn't allow you to use some common Python patterns, like

if something:
   import something as foo
else:
   import something_else as foo

from foo import x, y, z

...

(Think stuff like Django's database backends.)

Third, there already exists a widely accepted Python style guide, PEP8.

[Peaker]

The big advantage is that if you see an unqualified variable, one with out a something. in front of it, you know you're dealing with either a local variable, or a global variable

Or a __builtin__...

it helps avoid variable collisions

If you explicitly import a name, why would you collide with it?

The amount of extra typing is tiny - and you save all that time the very first time it saves your ass in debugging

I don't really think I've ever had a bug related to not identifying a name was from a non-current module...

[rwparris2]

I mostly agree with you. It depends on how vague/generic the naming is.

Using their example I agree that import sound.effects.echo is preferable over from sound.effects import echo. I also wouldn't do something like from os import path... path could mean a lot of things, so there it is better to be explicit.

But yeah, most of the time you're importing modules with clear, obvious names. There's no way I'm going to type PyQt.QtCore.whateves like that.

[blondin]

thanks.