Open Stack

On 08/05/2013 11:26 PM, Robert Collins wrote:
> I wanted to get a temperature reading from everyone on this style guideline.
> 
> My view on it is that it's a useful heuristic but shouldn't be a
> golden rule applied everywhere. Things like matches are designed to be
> used as a dsl:
>     self.assertThat(foo, Or(Equals("1"), Equals("2")))
> 
> rather than what H302 enforces:
>     self.assertThat(foo, matchers.Or(matchers.Equals("1"),
> matchers.Equals("2")))
> 
> Further, conflicting module names become harder to manage, when one
> could import just the thing.
> 
> Some arguments for requiring imports of modules:
>  - makes the source of symbols obvious
>    - Actually, it has no impact on that as the import is still present
> and clear in the file. import * would obfuscate things, but I'm not
> arguing for that.
>    - and package/module names can (and are!) still ambiguous. Like
> 'test.' - whats that? -> consult the imports.
>  - makes mocking more reliable
>    - This is arguably the case, but it's a mirage: it isn't a complete
> solution because modules still need to be mocked at every place they
> are dereferenced : only import modules helps to the extent that one
> never mocks modules. Either way this failure mode of mocking is
> usually very obvious IME : but keeping the rule as a recommendation,
> *particularly* when crossing layers to static resources is a good
> idea.
>  - It's in the Google Python style guide
> (http://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Imports#Imports)
>    - shrug :)
> 
> What I'd like us to do is weaken it from a MUST to a MAY, unless noone
> cares about it at all, in which case lets just turn it off entirely.

Enforcing it is hard. The code that does it has to import and then make
guesses on failures.

Also - I agree with Robert on this. I _like_ writing my code to not
import bazillions of things... but I think the hard and fast rule makes
things crappy at times.