Importing modules in Python is best practice

Question

I'm new to Python, because I want to expand the skills that I learned using R. In R, I tend to load a bunch of libraries, sometimes leading to function name conflicts.

Which is best for Python. I saw some specific options that I do not see the difference between

import pandas , from pandas import * and from pandas import DataFrame

What is the difference between the first two, and I should just import what I need. In addition, what will be the worst consequences for those who make small programs for processing data and calculating simple statistics.

UPDATE

I found this great guide . That explains everything.

Answer 1

import pandas imports the import pandas module in the pandas namespace, so you will need to call the objects in pandas using pandas.foo .

from pandas import * imports all the objects from the pandas module into the current namespace, so you call the objects in pandas using only foo . Keep in mind that this can have unexplained consequences if there are conflicts between your current namespace and the pandas namespace.

from pandas import DataFrame is the same as above, but only imports the DataFrame (instead of everything) into your current namespace.

In my opinion, the first, as a rule, is the best practice, as it supports various modules that are perfectly separated in your code.

Answer 2

Lack of each form

When reading the code of other people (and these people use very different import styles), I noticed the following problems with each of the styles:

import modulewithaverylongname will clutter the code further down with a long module name (for example, concurrent.futures or django.contrib.auth.backends ) and a decrease in readability in these places.

from module import * does not allow me to syntactically see that, for example, classA and classB come from the same module and have much in common with each other. This makes code reading tough. (This name from such an import is possible; shadow names from an earlier import are the smallest part of this problem.)

from module import classA, classB, functionC, constantD, functionE overloads my short-term memory with too many names that I mentally have to assign module to coordinate the code.

import modulewithaverylongname as mwvln sometimes not enough mnemonic for me.

Suitable compromise

Based on the above observations, I developed the following style in my own code:

import module is the preferred style if the module name is short such as most packages in the standard library. This is also the preferred style if I need to use names from a module in only two or three places in my own module; ( "Readability metrics" ).

import longername as ln is the preferred style in almost every other case. For example, I could import django.contrib.auth.backends as dj_abe . By the definition of the above criterion 1, the abbreviation will be used often and therefore easy to remember.

Only these two styles are completely pythonic according to "Explicit rule is better than implicit." .

from module import xx still occurs sometimes in my code. I use it in cases where even the as format looks exaggerated, the most famous example is from datetime import datetime .

Answer 3

In general, it is better to do explicit imports. How in:

 import pandas frame = pandas.DataFrame() 

Or:

 from pandas import DataFrame frame = DataFrame() 

Another option in Python when you have conflicting names is import x as y:

 from pandas import DataFrame as PDataFrame from bears import DataFrame as BDataFrame frame1 = PDataFrame() frame2 = BDataFrame() 

Answer 4

Here are some guidelines from the PEP8 Style Guide.

• Import usually should be in separate lines , for example:

   Yes: import os import sys No: import sys, os 

  but it normal

   from subprocess import Popen, PIPE 

• Import is always placed at the top of the file immediately after comments and module docking lines, as well as before globals and module constants.
  

  • Import should be grouped in the following order:
    • import standard library
    • Third Party Related Imports
    • import local applications / libraries
  • You must put an empty line between each import group.

• Absolute Import Recommended
  They are more readable and make debugging easier by providing improved error messages if you mess up the import system.

   import mypkg.sibling from mypkg import sibling from mypkg.sibling import example 

  or explicitly relative imports

   from . import sibling from .sibling import example 

• Implicit relative imports should never be used and removed in Python 3.

   No: from ..grand_parent_package import uncle_package 

• Importing wildcards ( from <module> import * ) should be avoided because they are unclear which names are present in the namespace, confusing readers as well as many automated tools.

  / li>

---

Some recommendations on lazy imports from python performance tips.

Import overhead

Import statements

can be performed almost anywhere. It is often useful to place them inside functions in order to limit their visibility and / or reduce the initial launch time. Although the Python interpreter is optimized so as not to import the same module multiple times, re-executing the import statement can seriously affect performance in some circumstances.

the script below, described on the page,

 >>> def doit1(): ... import string ... string.lower('Python') ... >>> import string >>> def doit2(): ... string.lower('Python') ... >>> import timeit >>> t = timeit.Timer(setup='from __main__ import doit1', stmt='doit1()') >>> t.timeit() 11.479144930839539 >>> t = timeit.Timer(setup='from __main__ import doit2', stmt='doit2()') >>> t.timeit() 4.6661689281463623 

Answer 5

 from A import B 

essentially equal to the following three statements

 import A B = AB del A 

What is it, that’s all.

Answer 6

They all fit in different contexts (which is why they are all available). There is no deep guiding principle other than generic affirmations of motherhood in clarity, maintainability and simplicity. Some examples from my own code:

• import sys, os, re, itertools avoids name conflicts and provides a very concise way to import several standard modules.
• from math import * allows you to write sin(x) instead of math.sin(x) in math code. This gets a little risky when I also import numpy, which doubles on some of them, but that doesn’t bother me too much, as they are usually the same anyway. In addition, I tend to follow the numpy documentation - import numpy as np , which completely wraps the problem.
• I approve from PIL import Image, ImageDraw only because the way the PIL documentation presents its examples.