Disadvantage of each form

When reading other people's code (and those people use verydifferent importing styles), I noticed the following problems witheach of the styles:

import modulewithaverylongname will clutter the code further downwith the long module name (e.g. concurrent.futures or django.contrib.auth.backends) and decrease readability in those places.

from module import * gives me no chance to see syntactically that,for instance, classA and classB come from the same module andhave a lot to do with each other.It makes reading the code hard.(That names from such an importmay shadow names from an earlier import is the least part of that problem.)

from module import classA, classB, functionC, constantD, functionEoverloads my short-term memory with too many namesthat I mentally need to assign to module in order tocoherently understand the code.

import modulewithaverylongname as mwvln is sometimes insufficientlymnemonic to me.

A suitable compromise

Based on the above observations, I have developed the followingstyle in my own code:

import module is the preferred style if the module name is shortas for example most of the packages in the standard library.It is also the preferred style if I need to use names from the module inonly two or three places in my own module;clarity trumps brevity then ("Readability counts").

import longername as ln is the preferred style in almost everyother case.For instance, I might import django.contrib.auth.backends as djcab.By definition of criterion 1 above, the abbreviation will be usedfrequently and is therefore sufficiently easy to memorize.

Only these two styles are fully pythonic as per the"Explicit is better than implicit." rule.

from module import xx still occurs sometimes in my code.I use it in cases where even the as format appears exaggerated,the most famous example being from datetime import datetime(but if I need more elements, I will import datetime as dt).

import pandas imports the pandas module under the pandas namespace, so you would need to call objects within pandas using pandas.foo.

from pandas import * imports all objects from the pandas module into your current namespace, so you would call objects within pandas using only foo. Keep in mind this could have unexepcted consequences if there are any naming conflicts between your current namespace and the pandas namespace.

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

In my opinion the first is generally best practice, as it keeps the different modules nicely compartmentalized in your code.

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

import pandasframe = pandas.DataFrame()

Or:

from pandas import DataFrameframe = DataFrame()

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

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