Open Stack

Excerpts from Robert Collins's message of 2013-08-05 19:26:20 -0700:
> 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.


You've convinced me. Monty's point about the complexity of making sure
what is imported in code is actually a module makes it expensive without
much benefit.

I say remove it entirely.