Python packages import

Question

I want to know why we use from module import module ?

For example from BeautifulSoup import BeautifulSoup instead of only import BeautifulSoup .

Are both of those different?

And if yes, then how?

Answer 1

Yes, they are different.

There are several ways to import a module

1. import module

   The module is imported, but all its functions, classes and variables remain within the name space of 'module. To reference them, they must be prepended with the module name:

   module.somefunction() module.someclass() module.somevariable = 1

2. import module as md

   The module is imported, but given a new name space 'md'. To reference the functions, classes and variables, they must be prepended with the new namespace:

   md.somefunction() module.someclass() module.somevariable = 1

   This keeps the namespaces separated, but provides a shorthand notation which makes the code more readable.

3. from module import *

   All functions, classes and variabes from the module are imported into the current namespace as if they were defined in the current module. They can be called with their own name:

   somefunction() someclass() somevariable = 1

   The disadvantage is that there might be overlapping names!

4. from module import something from module import something, somethingelse

   This imports only 'something' (and 'somethingelse') a function, a class, a variable into the current namespace.

   This is not only more efficient, but it also reduces the risk of overlapping names.

A module name and a class inside the module may have the same name. Don't let that confuse you:

import BeautifulSoup reference: BeautifulSoup.BeautifulSoup()

from BeautifulSoup import BeautifulSoup reference: BeautifulSoup()

import BeautifulSoup as bs reference: bs.BeautifulSoup()

Answer 2

I think it comes down to what the individual library (Python package ) owner wants to do and however they think it will be easiest for people to use their product. As part of the Python community, they may take into account the current conventions. Those may be done formally as a PEP like PEP 8 , informally through common practice, or as third-party formalized linters.

It can be confusing that there are some distinctions, like package vs module, that have the potential to help with understanding, but do not really mean anything to a Python application itself. For example, with your example, it is not from module import module ; it is more like from package import class for BeautifulSoup . But it could be argued that a package is an external module. I have heard some call any file a module and any directory a package.

---

More background, if you are new to python:

In python it is all about namespacing. Namespacing has the potential to allow for very clean and flexible code organization compared to earlier languages. However it also allows that any package, module, class, function, method, variable, or whatever name can be hard for someone writing a client application to know what is what. There is even a convenience class in the standard library for faking it: types.Namespace . Then there are metaclasses and dynamic programming as well. Anyway, yes there are common conventions followed to reduce confusion, but they have to be learned separately from the language itself (like learning customs of a country, not only its language, to be able to understand common phrases).

What PEP 20 has to say about namespaces:

import this

Back to PEP 8, generally, it is accepted that classes are word-uppercase ( class SomeClass: ) without underscores, and functions, variables and methods are all lowercase with words separated by underscores ( some_variable ). Not always the case, but those are probably the most widely accepted styles. Somewhere I see things going against what is "pythonic" and/or commonplace is when a bindings library is a thin wrapper around a library from another language (eg C++) or when the Python code is tightly coupled with code in another language, so the styles smear together for easier transitions. Nothing says anyone has to follow specific style.

Some people prefer terseness, so they may shorten and combine words for variable names (eg foo bar as fb ). Others may like to be explicit (eg foo bar as foo_bar ). And still others may prefer to be generic and use comments to describe their variables (why? it may be convenient for large complex equations):

# x is for foo bar.
# y is for spam and z is for ham.
assert x + y != z

Some people really like formatters like Black that follow very strict rules, but others like flexibility or have reason to go against convention. Even in the standard libraries that come with Python, there are inconsistency from legacy code that the maintainers have left alone or allowed before the community settled on common practices that the code goes against.