In order to simplify my imports, I added the following code to my __init__.py:
from varro.algo.models.model import *
from varro.algo.models.fpga import *
from varro.algo.models.nn import *
so that I can do from varro.algo.models import ModelNN
If I want to import a different kind of model that doesn't require Tensorflow (as ModelNN does), I don't want to import it, as it takes a long time to load and may not be installed on all systems I'm working on.
However, importing from varro.algo.models import ModelFPGA loads Tensorflow, even though I never import ModelNN.
Is there a way I can simplify the imports without having to import ModelNN every time? (I figured I could just put the import statement for Tensorflow in the class itself, but I want a more robust solution.)
I want to structure imports of my python module/package, namely I have several *.py files in my module. All of them use:
import numpy as np
in some pf them I use:
import pandas as pd
can I set the global import for my python module, and say that it uses numpy as np in all the *.py files of the module.
I tried something in __init__.py but it didn't work as expected. Is it anyhow reasonable to make global imports?
No, you cannot do this, it is fundamentally opposed to the way Python works.
Warning:- Do not use this at home.Not a good practice
You can Do it by importing all your libraries into a single file. For example:-
library.py
import numpy as np
import os
import json
import pandas as pd
And then import this file in your code files
main.py
from library import *
a = np.array([1, 2, 3])
Google's style guide says, about imports, that modules might be aliased with import xyz as x when x is a common abbreviation for xyz.
What are the standard abbreviations for the most common modules?
I'm here looking for a list exhaustive as possible, including modules from the standard library, as well as third-party niche packages that are frequently used in their respective fields.
For instance, numpy is always imported as np, and tkinter, when hopefully not imported with from module import *, is generally imported as tk.
Here are the names I see most of the time for the modules I frequently use.
This list is not meant to become an absolute reference, but I hope it will help provide some guidelines.
Please feel free to complete it, or to change whatever you think needs to be changed.
The import statements follow the conventions established by Google's Python style guide, namely:
Use import x for importing packages and modules.
Use from x import y where x is the package prefix and y is the module name with no prefix.
Use from x import y as z if two modules named y are to be imported or if y is an inconveniently long name.
Use import y as z only when z is a standard abbreviation (e.g., np for numpy).
MODULE ALIAS IMPORT STATEMENT
datetime dt import datetime as dt
matplotlib.pyplot plt from matplotlib import pyplot as plt
multiprocessing mp import multiprocessing as mp
numpy np import numpy as np
pandas pd import pandas as pd
seaborn sns import seaborn as sns
tensorflow tf import tensorflow as tf
tkinter tk import tkinter as tk
I am very new to Python and Behave. In my step file, test_steps.py, I have imported the following:
from behave import given, when, then, step
from behave_http.steps import *
from datetime import datetime
import time
import pdb
import xmltodict
import requests
If I created another step file, test2_steps.py, I had to import above again.
Is there a way to avoid that?
Thank you for your help!
It's generally useful to know all the imports for a given file; however, you can do something like the following:
config.py
from behave import given, when, then, step
from behave_http.steps import *
from datetime import datetime
import time
import pdb
import xmltodict
import requests
test2_steps.py
from config import *
#other code here
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.