Efficiency/style issues of import <module> vs. from <module>import <name>, ...
in [Python]
|
Prev: Serializing functions
Next: super() woes (n00b)
From: Stephen Hansen on 17 Jun 2010 12:33 On 6/17/10 9:12 AM, python(a)bdurham.com wrote: > Are there any efficiency or style guidelines regarding the choice > of "import <module>" vs. "from <module> import <name>, ..."? There are no legitimate efficiency issues. In theory, module.blah is slightly slower then blah, but that "slightly" is largely irrelevant in globals. If you need to do module.blah a lot in a loop, you want to re-bind it into a local anyways before that loop if performance starts mattering that much. Style wise, the only guideline is, "from <module> import *" is often (but not always) bad. It pollutes the namespace, making it difficult to know exactly what's defined and where it is defined. Multiple "import *"'s are especially bad. Explicitly importing certain names is perfectly fine. Its clear and explicit. Someone seeing, "MyRandomClass" can search in the code and they'll find that import and know precisely where to go to look for it. > If one only needs to import a few names from a module, are there > specific benefits to explictly importing these names? Clarity, sometimes. There is no general rule here though. It depends on the structure and layout. Its a case-by-case situation; is it more clear to your natural reading to have 'module.MyRandomThing' or just 'MyRandomThing' in your code? An example: let's say you have a "handlers" module containing certain... uh.. handlers.. you have defined for your application. You could either: import handlers Or: from handlers import MyHTTPHandler, MySMTPHandler, MyNNTPHandler In this case, I'd consider it possible that in code usage, its entirely sufficient to call "MyHTTPHandler" and have it be clear and understandable for future non-you coders. "handlers.MyHTTPHandler" is slightly more explicit, but due to the naming and structure of this specific code, redundant as well. That may not always hold true. Now, this is all IMHO: the style guide does not define any 'guidelines' on this, except that its okay to use "from ... import ..." to pull in classes and (implicitly) constants, and despite how the rules say 'one module per line' its OK to pull in more then one name -from- a module at once. > My understanding is that both forms of the import command require > the entire module to be processed. Yes. "from <module> import <name>" is just a shortcut for: import <module> <name> = <module>.<name> -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: Ethan Furman on 17 Jun 2010 13:01 Stephen Hansen wrote: > On 6/17/10 9:12 AM, python(a)bdurham.com wrote: > > Now, this is all IMHO: the style guide does not define any 'guidelines' > on this, except that its okay to use "from ... import ..." to pull in > classes and (implicitly) constants, and despite how the rules say 'one > module per line' its OK to pull in more then one name -from- a module at > once. What do you mean by "(implicitly) constants"? >> My understanding is that both forms of the import command require >> the entire module to be processed. > > Yes. > > "from <module> import <name>" is just a shortcut for: > > import <module> > <name> = <module>.<name> There should also be a third line: del <module> ~Ethan~
From: Stephen Hansen on 17 Jun 2010 12:58 On 6/17/10 10:01 AM, Ethan Furman wrote: > Stephen Hansen wrote: >> On 6/17/10 9:12 AM, python(a)bdurham.com wrote: >> >> Now, this is all IMHO: the style guide does not define any 'guidelines' >> on this, except that its okay to use "from ... import ..." to pull in >> classes and (implicitly) constants, and despite how the rules say 'one >> module per line' its OK to pull in more then one name -from- a module at >> once. > > What do you mean by "(implicitly) constants"? Quote, PEP-8: - Imports should usually be on separate lines, e.g.: Yes: import os import sys No: import sys, os it's okay to say this though: from subprocess import Popen, PIPE It explicitly states later its entirely OK to import classes. It never says anything else directly, except in the example given, it shows you importing a constant. So, its giving implicit approval to that without really directly saying anything about it. >>> My understanding is that both forms of the import command require >>> the entire module to be processed. >> >> Yes. >> >> "from <module> import <name>" is just a shortcut for: >> >> import <module> >> <name> = <module>.<name> > > > There should also be a third line: > del <module> You're right, I missed that. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: Ethan Furman on 17 Jun 2010 13:24 Stephen Hansen wrote: > On 6/17/10 10:01 AM, Ethan Furman wrote: >> Stephen Hansen wrote: >>> On 6/17/10 9:12 AM, python(a)bdurham.com wrote: >>> >>> Now, this is all IMHO: the style guide does not define any 'guidelines' >>> on this, except that its okay to use "from ... import ..." to pull in >>> classes and (implicitly) constants, and despite how the rules say 'one >>> module per line' its OK to pull in more then one name -from- a module at >>> once. >> What do you mean by "(implicitly) constants"? > > Quote, PEP-8: > > - Imports should usually be on separate lines, e.g.: > > Yes: import os > import sys > > No: import sys, os > > it's okay to say this though: > > from subprocess import Popen, PIPE > > It explicitly states later its entirely OK to import classes. It never > says anything else directly, except in the example given, it shows you > importing a constant. So, its giving implicit approval to that without > really directly saying anything about it. Thanks for the clarification -- I was reading it as constants being implicitly imported, and I knew that wasn't so! ;) ~Ethan~
From: Ethan Furman on 17 Jun 2010 13:51
Jack Diederich wrote: > You want to import a name that is itself a namespace; preferably a > module or package and sometimes a class. Importing constants can lead > to trouble. ex/ > > from settings import DEBUG > if DEBUG: log('debug is on!') > > The value of the flag gets fetched at import time. If code in another > module updates settings.DEBUG later your module won't see it. ditto > for exceptions. > > -Jack The idea behind constants is that they are... um... constant. ;) I imagine exceptions don't get changed often either. (At least, I never change mine.) If you have a setting that may change, don't call it a constant and name it accordingly. ~Ethan~ |