I want to write a Python module that automatically imports all the good stuff for me (about 50 other modules) so I don't have to copy and past them every time I start a new script. I attempted this by defining the following method in my module, soon to realize when I import my module and call this method, the imports take place locally.
def auto_import():
import os
import sys
# plus 50 other modules...
How can I accomplish this automation using modular programming? (I am using Python 3.6. on Ubuntu.)
You don't need a function to do that, you can simply make a file like commonimports.py which looks like this:
import os
import numpy as np
import sys
#and so on...
And add this import statement in other files
from commonimports import *
And you'll have all the modules ready to use within that namespace
Just make the name of your imported modules global:
def auto_import():
import os
import sys
global os, sys
This is not necessary to use this method if you def auto_import() then every time you have to use a autoimport function whenever you want to use those module.
I thought the correct order of imports in Python was the one described by the first answer of the question: What's the correct way to sort Python `import x` and `from x import y` statements?
Therefore, this code should be correct:
import os
import time
import yaml
from collections import OrderedDict
from xtesting.core import testcase
However, when I run Pylint I get:
C: 5, 0: standard import "from collections import OrderedDict" should be placed before "import yaml" (wrong-import-order)
So I guess "yaml" is not a standard library. Should then the correct way to do it be this one (even if it is uglier and less readable)?
import os
import time
from collections import OrderedDict
import yaml
from xtesting.core import testcase
PyYAML is not part of the standard Python library and imports from the standard library, whether generic (import os) or specific (from collections import OrderedDict) should come first.
You should, IMO, lexicographically sort on the module names in the sections and separate the sections with an empty line:
from collections import OrderedDict
import os
import time
from xtesting.core import testcase
import yaml
There are some that want the generic ones to all come first, in each section:
import os
import time
from collections import OrderedDict
import yaml
from xtesting.core import testcase
This looks nicer, but it makes it easier to overlook specific imports after a long generic lists. And it also separates a generic and specific import from one and the same module, which, IMO, is bad:
import yaml
from xtesting.core import testcase
from yaml import safe_load
I am new to python. I am confused with importing in python and I am using two python files.
re1.py:
import datetime
import re2
re2.py:
print datetime.datetime.now()
When I run the re1.py file, it gave the error,
print datetime.datetime.now()
NameError: name 'datetime' is not defined
What is the best way to solve this error ?
When you import datetime in re1.py, you import it in the scope of only the re1.py file, and not in re2.py. In other words, if you import something in one module, it won't cross over onto the other.
To fix this, you must import datetime in re2.py (and you don't necessarily need it in re1.py)
your code should be:
re1.py:
import datetime
import re2
re2.py:
import datetime
print datetime.datetime.now()
import re2 doesn't means simply replace the statement with another file:
import datetime
# re2.py
import datetime
print datetime.datetime.now()
you have to make sure all the modules you import are working.
When importing modules in Python, what is the difference between this:
from module import a, b, c, d
and this
from module import a
from module import b
from module import c
from module import d
To me it makes sense always to condense code and use the first example, but I've been seeing some code samples out there dong the second. Is there any difference at all or is it all in the preference of the programmer?
There is no difference at all. They both function exactly the same.
However, from a stylistic perspective, one might be more preferable than the other. And on that note, the PEP-8 for imports says that you should compress from module import name1, name2 onto a single line and leave import module1 on multiple lines:
Yes: import os
import sys
No: import sys, os
Ok: from subprocess import Popen, PIPE
In response to #teewuane's comment (repeated here in case the comment gets deleted):
#inspectorG4dget What if you have to import several functions from one
module and it ends up making that line longer than 80 char? I know
that the 80 char thing is "when it makes the code more readable" but I
am still wondering if there is a more tidy way to do this. And I don't
want to do from foo import * even though I am basically importing
everything.
The issue here is that doing something like the following could exceed the 80 char limit:
from module import func1, func2, func3, func4, func5
To this, I have two responses (I don't see PEP8 being overly clear about this):
Break it up into two imports:
from module import func1, func2, func3
from module import func4, func5
Doing this has the disadvantage that if module is removed from the codebase or otherwise refactored, then both import lines will need to be deleted. This could prove to be painful
Split the line:
To mitigate the above concern, it may be wiser to do
from module import func1, func2, func3, \
func4, func5
This would result in an error if the second line is not deleted along with the first, while still maintaining the singular import statement
To add to some of the questions raised from inspectorG4dget's answer, you can also use tuples to do multi-line imports when folder structures start getting deeply nested or you have modules with obtuse names.
from some.module.submodule.that_has_long_names import (
first_item,
second_item,
more_imported_items_with_really_enormously_long_names_that_might_be_too_descriptive,
that_would_certainly_not_fit,
on_one_line,
)
This also works, though I'm not a fan of this style:
from module import (a_ton, of, modules, that_seem, to_keep, needing,
to_be, added, to_the_list, of_required_items)
I would suggest not to follow PEP-8 blindly. When you have about half screen worth of imports, things start becoming uncomfortable and PEP-8 is then in conflicts with PEP-20 readability guidelines.
My preference is,
Put all built-in imports on one line such as sys, os, time etc.
For other imports, use one line per package (not module)
Above gives you good balance because the reader can still quickly glance the dependencies while achieving reasonable compactness.
For example,
My Preference
# one line per package
import os, json, time, sys, math
import numpy as np
import torch, torch.nn as nn, torch.autograd, torch.nn.functional as F
from torchvision models, transforms
PEP-8 Recommandation
# one line per module or from ... import statement
import os
import json
import time
import sys
import math
import numpy as np
import torch
from torch import nn as nn, autograd, nn.functional as F
from torchvision import models, transforms
A concern not mentioned by other answers is git merge conflicts.
Let's say you start with this import statement:
import os
If you change this line to import os, sys in one branch and import json, os in another branch, you will get this conflict when you attempt to merge them:
<<<<<<< HEAD
import os, sys
=======
import json, os
>>>>>>> branch
But if you add import sys and import json on separate lines, you get a nice merge commit with no conflicts:
--- a/foo.py
+++ b/foo.py
### -1,2 -1,2 +1,3 ###
+ import json
import os
+import sys
You will still get a conflict if the two imports were added at the same location, as git doesn't know which order they should appear in. So if you had imported time instead of json, for example:
import os
<<<<<<< HEAD
import sys
=======
import time
>>>>>>> branch
Still, it can be worth sticking with this style for the occasions where it does avoid merge conflicts.
Imports should usually be on separate lines as per PEP 8 guidelines.
# Wrong Use
import os, sys
# Correct Use
import os
import sys
For more import based PEP 8 violations and fixes please check this out https://ayush-raj-blogs.hashnode.dev/making-clean-pr-for-open-source-contributors-pep-8-style.
Both are same.
Use from module import a, b, c, d.
If you want to import only one part of a module, use:
from module import a
If u want to import multiple codes from same module, use:
from module import a,b,c,d
No need to write all in separate lines when both are same.
I recently managed to get SimpleCV up and running, after running into some issues. I now have a working SimpleCV installed and am using it with Eclipse Indigo. However, all my imports from SimpleCV are marked in red, and Eclipse states that it cannot find the specified import (even though the imported functions work fine).
Is there any way to have Eclipse recognize the imports from SimpleCV, so that I can make use of its Ctrl-Space code-complete functionality?
I tried to add "SimpleCV" to the Forced Builtins, but with no success. (This is what I did when I had the same problem for OpenCV, and it worked then)
Thanks for any advice!
Imports are very much broken in SimpleCV. I've been struggling with the same problem you're having. And the reason they don't want to fix it (as per their answers on their site (http://help.simplecv.org/question/472/code-completion-with-eclipse/) is not because they "all use vim, emacs, vi" but because a lot of their code relies on pulling alot of libraries into the local namespace with * imports. It's lazy programming at best, and really bad programming otherwise.
Heck, you can't even import some of their files by themselves because they rely on the SimpleCV init.py file and base.py file being imported already. Both of those files have a lot of blanket imports. I was wondering why import SimpleCV took more than 2 seconds to run on my pc with an SSD. Now I know.
Their init.py file has these imports:
from SimpleCV.base import *
from SimpleCV.Camera import *
from SimpleCV.Color import *
from SimpleCV.Display import *
from SimpleCV.Features import *
from SimpleCV.ImageClass import *
from SimpleCV.Stream import *
from SimpleCV.Font import *
from SimpleCV.ColorModel import *
from SimpleCV.DrawingLayer import *
from SimpleCV.Segmentation import *
from SimpleCV.MachineLearning import *
And their base.py file has yet more imports:
import os
import sys
import warnings
import time
import socket
import re
import urllib2
import types
import SocketServer
import threading
import tempfile
import zipfile
import pickle
import glob #for directory scanning
import abc #abstract base class
import colorsys
import logging
import pygame as pg
import scipy.ndimage as ndimage
import scipy.stats.stats as sss #for auto white balance
import scipy.cluster.vq as scv
import scipy.linalg as nla # for linear algebra / least squares
import math # math... who does that
import copy # for deep copy
import numpy as np
import scipy.spatial.distance as spsd
import scipy.cluster.vq as cluster #for kmeans
import pygame as pg
import platform
import copy
import types
import time
from numpy import linspace
from scipy.interpolate import UnivariateSpline
from warnings import warn
from copy import copy
from math import *
from pkg_resources import load_entry_point
from SimpleHTTPServer import SimpleHTTPRequestHandler
from types import IntType, LongType, FloatType, InstanceType
from cStringIO import StringIO
from numpy import int32
from numpy import uint8
from EXIF import *
from pygame import gfxdraw
from pickle import *
You know they claim to convert all these disparate CV libraries and apply "Pythonic" ways to them. But this import mess just plain out right proves them wrong.
My attempt at fixing their imports was to remove all those import *'s from their init.py file which helps with the code completion lag that it presents in eclipse. Then importing the SimpleCV egg directory (C:\Python27\Lib\site-packages\simplecv-1.3-py2.7.egg) into eclipse as an external library. After that, I was able to run this:
from SimpleCV.ImageClass import Image
Same goes for importing Color:
from SimpleCV.Color import Color
There are cyclical imports, so beware of those as they might bite you. I myself had one earlier while trying to import SimpleCV.Color before importing SimpleCV.ImageClass. Note, with the above instructions, I seem to be able to get code-completion from Eclipse.