Efficiency/style issues of import module vs. from module import name, ...
Are there any efficiency or style guidelines regarding the choice of import module vs. from module import name, ...? If one only needs to import a few names from a module, are there specific benefits to explictly importing these names? My understanding is that both forms of the import command require the entire module to be processed. If this comes down purely to preference, are there PEP 8-like standards regarding which approach to use when? Thanks, Malcolm -- http://mail.python.org/mailman/listinfo/python-list
Re: Efficiency/style issues of import module vs. from module import name, ...
On 6/17/10 9:12 AM, pyt...@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/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Efficiency/style issues of import module vs. from module import name, ...
Stephen Hansen wrote: On 6/17/10 9:12 AM, pyt...@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~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Efficiency/style issues of import module vs. from module import name, ...
On 6/17/10 10:01 AM, Ethan Furman wrote: Stephen Hansen wrote: On 6/17/10 9:12 AM, pyt...@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/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Efficiency/style issues of import module vs. from module import name, ...
Stephen Hansen wrote: On 6/17/10 10:01 AM, Ethan Furman wrote: Stephen Hansen wrote: On 6/17/10 9:12 AM, pyt...@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~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Efficiency/style issues of import module vs. from module import name, ...
On Thu, Jun 17, 2010 at 12:58 PM, Stephen Hansen
me+list/pyt...@ixokai.io wrote:
On 6/17/10 10:01 AM, Ethan Furman wrote:
Stephen Hansen wrote:
On 6/17/10 9:12 AM, pyt...@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.
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Efficiency/style issues of import module vs. from module import name, ...
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~
--
http://mail.python.org/mailman/listinfo/python-list
Re: Efficiency/style issues of import module vs. from module import name, ...
On 6/17/10 10:22 AM, Jack Diederich wrote:
On Thu, Jun 17, 2010 at 12:58 PM, Stephen Hansen
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.
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.
That argument is invalid on its face; a constant, by definition, is not
to be modified. The convention (recently adopted officially by PEP-8) of
ALL_CAPS makes this promise: this is a static piece of data.
That its possible for misbehaving code to change it due to Python's lax
nature doesn't mean you should organize or write your code in such a way
to take that into account. People can shoot themselves in the foot.
If people do stupid things after writing code that makes promises, stuff
that relies upon the explicit promises made may fail, and that's their
own dumb fault.
And the only time someone is going to go 'change' an exception that
lives in the top-level of some other module is if they're
monkey-patching, which while a legitimate technique to achieve certain
ends when using other people's code-- is also not a technique which has
any place in consideration of the design phase of the original system
itself.
Certainly, importing a non-constant immutable piece of data is
problematic in theory, as it can be rebound and problems arise.
Number of times I've -seen- non-constant immutable data in the top-level
of a module: 0*.
--
Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/
P.S. Outside of a throw-away script which is not meant to be imported,
at least.
signature.asc
Description: OpenPGP digital signature
--
http://mail.python.org/mailman/listinfo/python-list
