Related
I've generally been told that the following is bad practice.
from module import *
The main reasoning (or so I've been told), is that you could possibly import something you didn't want, and it could shadow a similarly named function or class from another module.
However, what about PyQt
from PyQt4.QtCore import *
Every example I've ever seen is written this way, mainly because everything exported from Qt starts with "Q", so it's not going to shadow anything.
What's the concensus? Is it always bad to use * imports?
EDIT:
Just to be clear, this question is specifically in regards to using PyQt4. It has nothing to do with the way I am designing some other project.
Basically, I've found that coding to PEP8 has improved my code readability, except with regards to importing PyQt4, and so I've disregarded the frowns from purists until now. But now my dev group is deciding on one convention and I'm wondering if this is a scenario "where practicality beats purity", or if I should just suck it up and deal with monstrous PyQt4 imports
from PyQt4.QtGui import QComboBox, QLineEdit, QLayout, Q;lakdfaf.......
This can sort of turn into a religious war. It's a matter of whether you want to be explicit or whether you want to avoid being too verbose. In general, following the Zen of Python, it's better to be explicit, but sometimes people just don't find it practical to list every import from particular module.
My general rule is that if I didn't write the module, I don't import it all. My biggest fear is actually over writing local variables that might have been defined in the imported module. So to keep from having to type in long module names, I use the import as feature. Using your module as an example I would do the following:
import PyQt4.QtCore as qt
That being said, I have many support modules that I write that I will import everything. Like the pyqt module, I name them with a descriptive name that helps show which module it came from.
Edit per comment
When I use import*, my support modules do not contain classes or anything that can create a new instance. They tend to be groups of functions that modify existing instances only. To help clarify my opinion: If I am the owner of the source code and I will be the primary maintainer, I will use the import* otherwise I would use the import as.
Another reason that I use the import as feature is to allow me to mock modules for debugging purposes. In a project that I am working on now, I use pyVisa to talk to a number of GPIB devices. When I'm not connected to the devices GPIB network, I can use a dummy_visa module to write to the stdout(to verify I am sending the correct format) and return a random number (to test my application). See below
if visa_debug:
import dummy_visa as visa
else:
import visa
gpib = visa.Instrument("GPIB0::10")
gpib.write("MEAS:VOLT?")
Making an explicit exception for modules that already include a namespace in their naming convention (such as the Q* of PyQT) is perfectly reasonably. However, I recommend being clear that the default is still "don't use it" and simply list this exception in your coding guidelines.
import * is also acceptable when it is used as a namespace manipulation trick within an application (the two forms of that I am familiar with are optional C acceleration modules that are imported at the end of the pure Python version, and "flattening" a package namespace in __init__). The key point is that the importing module and the module being imported are under the control of the same set of developers, and hence avoiding namespace clashes is completely within their control.
The final exception is for convenience at the interactive prompt.
In other situations, it is best to either import specific names or reference them indirectly through the module name (or, if there are some commonly reference items, do both:
import module # Can access anything
from module import a, b, c # But we reference these a lot, so retrieve them directly
Tutorial, chapter 6:
Note that in general the practice of importing * from a module or package is frowned upon, since it often causes poorly readable code. However, it is okay to use it to save typing in interactive sessions.
Tutorial, chapter 10:
Be sure to use the import os style instead of from os import *. This will keep os.open() from shadowing the built-in open() function which operates much differently.
So it seems that it is definitely a bad idea sometimes; not-the-best idea most of the time; and an acceptable shortcut in cases where you'd want to type less, eg in interactive sessions.
I find import * gets abused, and can become a maintenance headache, so I avoid it for this and the other reasons you state. That said I feel it's okay for short interactive sessions, e.g. from pylab import *.
In production code, for packages like PyQt4.QtCore where you plan to use many of the symbols, I'd use one of the following syntaxes which make it explicit which namespace the symbols come from:
from PyQt4 import QtCore
# explicit where the symbol came from
QtCore.QTime()
import PyQt4.QtCore as QT
# less desirable since you need to look in the header to find out what QT is
# but I still prefer it to import *
QT.QTime()
In general, if you're going to use from X import Y, it's a good idea to be explicit about what you're importing. That's not just because it's safer, but also because it makes your code more readable (and upgrades to the third-party modules you're using won't have as much potential to incidentally break your code).
In some code examples demonstrating big packages, like Qt or matplotlib, the examples will use from module import * because they're often only importing from one module, and it saves typing and lets their example code get to the point. There's no reason you can't do it in your code, but at least use it in moderation, especially if it's in big source files or other people will be looking at your code.
The PyQt design is water under the bridge. I'm not sure it's the best thing, but it's probably influenced by the way Qt was designed. AFAIK, Qt didn't use C++ namespaces historically (I'm not sure if it uses them now), and therefore had to use prefixes. But all of those design decisions probably happened more than 10 years ago, and that shouldn't affect your design decisions now.
I know that if I was designing a library now, I would definitely choose to use package namespaces (which you would import explicitly in Python) over prefixes. Let's say my prefix is Pfx - if the library user doesn't care writing PfxFunc() every time he needs a function, he certainly wouldn't care about the extra character in Pfx.Func(), especially when he can use import with specific symbol names to shorten that even more.
Consider this case
from foo import *
from bar import *
x=baz()
Now suppose foo has a function called baz() that we are using in our code and everything is working fine. Months or years pass, the author of bar adds a function called baz(). Someone updates the egg ang bingo - we have a potentially hard to detect bug in the program.
Not to mention that just looking at those three lines of code, I can't tell where baz comes from without going and looking at foo and bar
The only time I'd use import * would be in the interpreter to save some typing
I've done some research, and I came across the following article: http://effbot.org/zone/import-confusion.htm. While this seems to be a great guide, it was written in 1999, a while back. I'm am using Python 3.4.3, so I am thinking that some things have changed, which worries me, because I don't want to learn what is not applicable. Therefore, in Python 3, what are all of the ways to import packages and modules, in detail? Which ways are the most common and should be used above others?
The only ways that matter for ordinary usage are the first three ways listed on that page:
import module
from module import this, that, tother
from module import *
These haven't changed in Python 3. (Some of the details about where Python looks for the module.py file to load module have been tweaked, but the behavior of the import itself still works as described on the page you linked.)
One thing has been added, before Python 3 but since that article. That is explicit relative imports. These let you do things like from ..module import blah. This kind of import can only be used from inside a package; it lets modules in a package refer to other modules in the same package in a way that is relative to the package (i.e., without having to specify how to import the top-level package). You can read the details in PEP 328. Even this, though, is basically just a new variation on the from module import blah style syntax mentioned on the page you linked to.
__import__ also still works in Python 3. This is an internal function that you only would need to use if doing something rather unusual. The same applies to various functions in the importlib module (and the deprecated imp module). The exact level of wizardliness of these importing functions varies from one to another, but for ordinary usage of "I just want to import this module and use it", you essentially never need to use them. They're only needed if you want to do something like dynamically import a module whose name isn't known until runtime.
The Zen of Python gives you some hints:
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
So given the simple, obvious method is: import module_name and it preserves namespaces I would suggest that while there are several import methods as you can see from the python3 manual entry and you can extend them by overriding the __import__() method or by rolling your own I would say stick with it until you have a good reason not to.
The fact that__import__() is surrounded by double underscores is also a hint to leave it alone.
If you are looking to understand the design decisions behind the import mechanisms then start with the manual then follow up into the PEPs 302 & 420 are good starting points.
I think import as tuple would be much better for readability and Maximum Line Length(pep8)
The import statement has two problems:
Long import statements can be difficult to write, requiring various
contortions to fit Pythonic style guidelines.
Imports can be ambiguous in the face of packages; within a package,
it's not clear whether import foo refers to a module within the package or some module outside the package.
golang language have the same thing for that
so would more prefer import kinda this
from package import (x, y)
instead of this
from authentication.views import SignupView, LoginView, VerificationView, SignupDetailView
https://legacy.python.org/dev/peps/pep-0328/
We can import modules in Python using the following ways
import module
from module import function
from module import *
Although using from module import *
is not a good practice, because of readability: Other programmer cannot understand what all are actually used in the current module. Memory overload: All are loaded in to memory. Best practices for using import in a module.
Say you have python modules (mymod1.py, mymod2.py files containing different functions) inside mypkg package (folder having init.py file, it can be an empty file).
#mymod1.py
def add_fun(a,b):
return a+b
def sub_fun(a,b):
return a-b
def mul_fun(a,b):
return a*b
def div_fun(a,b):
return a/b
#mymod2.py
def fun1(...):
........
........
def fun2(...):
........
........
Following are different ways to import:
from mypkg.mymod1 import * #import all the function from mymod1
add_fun(10, 20)
mul_fun(10, 2)
from mypkg.mymod1 import add_fun,div_fun #import only needed functions from mymod1
add_fun(10, 20)
div_mul(10, 2)
from mypkg import mymod1 #import mymod module
mymod1.add_fun(10, 20)
mymod1.mul_fun(10, 2)
import mypkg #import package and use different models inside it
mypkg.mymod1.add_fun(10, 20)
mypkg.mymod1.mul_fun(10, 2)
So, I have two scripts temperature.py and rain.py. These two scripts do the same thing: open a file, update it and then save it. The purpose of the functions is the same but the functions do it differently for each script.
My question is should I give the same name, ex. update(), to both scripts, all it should be different ?
I am going to import them like below:
import temperature
import rain
I would propose to use the same names, especially if you are not up to from temperature import * or similar nastinesses. The way you write you want to do it, there is no problem by calling rain.update() and temperature.update().
But maybe you should reconsider if your two "modules" shouldn't be better two classes which inherit from each other or at least from a common base class. If you want two things to "do the same, but differently", then overriding an inherited behaviour is the object-oriented way to do it. Maybe the two update()s even have something in common which both need to do (which is a very typical case); that could then be done in a base class then.
And even if you now would answer "no, they have nothing in common", I think I feel the idea of them having something in common on a more theoretical level. In that case, maybe later versions of your software would benefit from the different architecture I propose.
What about making the function specific and descriptive to the context?
from temperature import update_temperature
from rain import update_rain
Naming like this provides a lesser chance of naming conflicts (like both files having an update(), or even a third-party package having it's own update()).
It provides a clear understanding of what exactly your code is doing; updating the temperature (not the units temperature.update_units, or the location temperature.update_location) and states it.
I am refactoring a piece of Python 2 software. The code is currently in a single file, which contains 45 or so classes (and 2 lines outside of a class to bootstrap the application).
I'd like to have one class per file, with ideally files from related classes grouped in directories.
I typically like to write my Python imports as such:
from zoo.dog_classes.beagle_class import BeagleClass
from zoo.dog_classes.dalmatian_class import DalmatianClass
so that it is clear which modules are imported in the class, and that their name is as short as possible.
For this software, the logic is quite complex though, with classes referring to one another commonly in class methods, resulting in numerous circular imports, which rules out this approach.
I do not want to import modules in functions, as this is horrible for readability and code gets repeated everywhere.
It seems like my only option is to write imports in such a fashion:
import zoo.dog_classes.beagle_class
and later, when I need the class:
b = zoo.dog_classes.beagle_class.BeagleClass()
This is however extremely verbose and painful to write.
How should I deal with my imports?
import zoo.dog_classes.beagle_class as beagle
b = beagle.BeagleClass()
I've generally been told that the following is bad practice.
from module import *
The main reasoning (or so I've been told), is that you could possibly import something you didn't want, and it could shadow a similarly named function or class from another module.
However, what about PyQt
from PyQt4.QtCore import *
Every example I've ever seen is written this way, mainly because everything exported from Qt starts with "Q", so it's not going to shadow anything.
What's the concensus? Is it always bad to use * imports?
EDIT:
Just to be clear, this question is specifically in regards to using PyQt4. It has nothing to do with the way I am designing some other project.
Basically, I've found that coding to PEP8 has improved my code readability, except with regards to importing PyQt4, and so I've disregarded the frowns from purists until now. But now my dev group is deciding on one convention and I'm wondering if this is a scenario "where practicality beats purity", or if I should just suck it up and deal with monstrous PyQt4 imports
from PyQt4.QtGui import QComboBox, QLineEdit, QLayout, Q;lakdfaf.......
This can sort of turn into a religious war. It's a matter of whether you want to be explicit or whether you want to avoid being too verbose. In general, following the Zen of Python, it's better to be explicit, but sometimes people just don't find it practical to list every import from particular module.
My general rule is that if I didn't write the module, I don't import it all. My biggest fear is actually over writing local variables that might have been defined in the imported module. So to keep from having to type in long module names, I use the import as feature. Using your module as an example I would do the following:
import PyQt4.QtCore as qt
That being said, I have many support modules that I write that I will import everything. Like the pyqt module, I name them with a descriptive name that helps show which module it came from.
Edit per comment
When I use import*, my support modules do not contain classes or anything that can create a new instance. They tend to be groups of functions that modify existing instances only. To help clarify my opinion: If I am the owner of the source code and I will be the primary maintainer, I will use the import* otherwise I would use the import as.
Another reason that I use the import as feature is to allow me to mock modules for debugging purposes. In a project that I am working on now, I use pyVisa to talk to a number of GPIB devices. When I'm not connected to the devices GPIB network, I can use a dummy_visa module to write to the stdout(to verify I am sending the correct format) and return a random number (to test my application). See below
if visa_debug:
import dummy_visa as visa
else:
import visa
gpib = visa.Instrument("GPIB0::10")
gpib.write("MEAS:VOLT?")
Making an explicit exception for modules that already include a namespace in their naming convention (such as the Q* of PyQT) is perfectly reasonably. However, I recommend being clear that the default is still "don't use it" and simply list this exception in your coding guidelines.
import * is also acceptable when it is used as a namespace manipulation trick within an application (the two forms of that I am familiar with are optional C acceleration modules that are imported at the end of the pure Python version, and "flattening" a package namespace in __init__). The key point is that the importing module and the module being imported are under the control of the same set of developers, and hence avoiding namespace clashes is completely within their control.
The final exception is for convenience at the interactive prompt.
In other situations, it is best to either import specific names or reference them indirectly through the module name (or, if there are some commonly reference items, do both:
import module # Can access anything
from module import a, b, c # But we reference these a lot, so retrieve them directly
Tutorial, chapter 6:
Note that in general the practice of importing * from a module or package is frowned upon, since it often causes poorly readable code. However, it is okay to use it to save typing in interactive sessions.
Tutorial, chapter 10:
Be sure to use the import os style instead of from os import *. This will keep os.open() from shadowing the built-in open() function which operates much differently.
So it seems that it is definitely a bad idea sometimes; not-the-best idea most of the time; and an acceptable shortcut in cases where you'd want to type less, eg in interactive sessions.
I find import * gets abused, and can become a maintenance headache, so I avoid it for this and the other reasons you state. That said I feel it's okay for short interactive sessions, e.g. from pylab import *.
In production code, for packages like PyQt4.QtCore where you plan to use many of the symbols, I'd use one of the following syntaxes which make it explicit which namespace the symbols come from:
from PyQt4 import QtCore
# explicit where the symbol came from
QtCore.QTime()
import PyQt4.QtCore as QT
# less desirable since you need to look in the header to find out what QT is
# but I still prefer it to import *
QT.QTime()
In general, if you're going to use from X import Y, it's a good idea to be explicit about what you're importing. That's not just because it's safer, but also because it makes your code more readable (and upgrades to the third-party modules you're using won't have as much potential to incidentally break your code).
In some code examples demonstrating big packages, like Qt or matplotlib, the examples will use from module import * because they're often only importing from one module, and it saves typing and lets their example code get to the point. There's no reason you can't do it in your code, but at least use it in moderation, especially if it's in big source files or other people will be looking at your code.
The PyQt design is water under the bridge. I'm not sure it's the best thing, but it's probably influenced by the way Qt was designed. AFAIK, Qt didn't use C++ namespaces historically (I'm not sure if it uses them now), and therefore had to use prefixes. But all of those design decisions probably happened more than 10 years ago, and that shouldn't affect your design decisions now.
I know that if I was designing a library now, I would definitely choose to use package namespaces (which you would import explicitly in Python) over prefixes. Let's say my prefix is Pfx - if the library user doesn't care writing PfxFunc() every time he needs a function, he certainly wouldn't care about the extra character in Pfx.Func(), especially when he can use import with specific symbol names to shorten that even more.
Consider this case
from foo import *
from bar import *
x=baz()
Now suppose foo has a function called baz() that we are using in our code and everything is working fine. Months or years pass, the author of bar adds a function called baz(). Someone updates the egg ang bingo - we have a potentially hard to detect bug in the program.
Not to mention that just looking at those three lines of code, I can't tell where baz comes from without going and looking at foo and bar
The only time I'd use import * would be in the interpreter to save some typing