On Wed, Feb 25, 2015 at 9:47 PM, Doug Hellmann <d...@doughellmann.com> wrote:
> > > On Wed, Feb 25, 2015, at 02:59 PM, Robert Collins wrote: > > On 26 February 2015 at 08:54, melanie witt <melwi...@gmail.com> wrote: > > > On Feb 25, 2015, at 10:51, Duncan Thomas <duncan.tho...@gmail.com> > wrote: > > > > > >> Is there anybody who'd like to step forward in defence of this rule > and explain why it is an improvement? I don't discount for a moment the > possibility I'm missing something, and welcome the education in that case > > > > > > A reason I can think of would be to preserve namespacing (no > possibility of function or class name collision upon import). Another > reason could be maintainability, scenario being: Person 1 imports ClassA > from a module to use, Person 2 comes along later and needs a different > class from the module so they import ClassB from the same module to use, > and it continues. If only the module had been imported, everybody can just > do module.ClassA, module.ClassB instead of potentially multiple imports > from the same module of different classes and functions. I've also read it > doesn't cost more to import the entire module rather than just a function > or a class, as the whole module has to be parsed either way. > > > > I think the primary benefit is that when looking at the code you can > > tell where a name came from. If the code is using libraries that one > > is not familiar with, this makes finding the implementation a lot > > easier (than e.g. googling it and hoping its unique and not generic > > like 'create' or something. > > I think the rule originally came from the way mock works. If you import > a thing in your module and then a test tries to mock where it came from, > your module still uses the version it imported because the name lookup > isn't done again at the point when the test runs. If all external > symbols are accessed through the module that contains them, then the > lookup is done at runtime instead of import time and mocks can replace > the symbols. The same benefit would apply to monkey patching like what > eventlet does, though that's less likely to come up in our own code than > it is for third-party and stdlib modules. > I second Doug's analysis. I've already had a hard time figuring out why mock wasn't doing what I wanted it to do and following H302 just fixed it... BR, Simon > > Doug > > > > > -Rob > > > > -- > > Robert Collins <rbtcoll...@hp.com> > > Distinguished Technologist > > HP Converged Cloud > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
