On 26 February 2015 at 08:54, melanie witt <[email protected]> wrote: > On Feb 25, 2015, at 10:51, Duncan Thomas <[email protected]> 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. -Rob -- Robert Collins <[email protected]> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
