Open Stack

On Wed, Feb 25, 2015 at 9:47 PM, Doug Hellmann <doug at doughellmann.com>
wrote:

>
>
> On Wed, Feb 25, 2015, at 02:59 PM, Robert Collins wrote:
> > On 26 February 2015 at 08:54, melanie witt <melwittt at gmail.com> wrote:
> > > On Feb 25, 2015, at 10:51, Duncan Thomas <duncan.thomas at 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 <rbtcollins at hp.com>
> > Distinguished Technologist
> > HP Converged Cloud
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150226/8a3ef515/attachment.html>