What Exactly Does "Import *" Import

What exactly does import * import?

The "advantage" of from xyz import * as opposed to other forms of import is that it imports everything (well, almost... [see (a) below] everything) from the designated module under the current module. This allows using the various objects (variables, classes, methods...) from the imported module without prefixing them with the module's name. For example

>>> from math import *
>>>pi
3.141592653589793
>>>sin(pi/2)
>>>1.0

This practice (of importing * into the current namespace) is however discouraged because it

provides the opportunity for namespace collisions (say if you had a variable name pi prior to the import)
may be inefficient, if the number of objects imported is big
doesn't explicitly document the origin of the variable/method/class (it is nice to have this "self documentation" of the program for future visit into the code)

Typically we therefore limit this import * practice to ad-hoc tests and the like. As pointed out by @Denilson-Sá-Maia, some libraries such as (e.g. pygame) have a sub-module where all the most commonly used constants and functions are defined and such sub-modules are effectively designed to be imported with import *. Other than with these special sub-modules, it is otherwise preferable to ...:

explicitly import a few objects only

>>>from math import pi
>>>pi
>>>3.141592653589793
>>> sin(pi/2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'sin' is not defined

or import the module under its own namespace (or an alias thereof, in particular if this is a long name, and the program references its objects many times)

  >>>import math
  >>>math.pi
  >>>3.141592653589793
  etc..

  >>>import math as m  #bad example math being so short and standard...
  >>>m.pi
  >>>3.141592653589793
  etc..

See the Python documentation on this topic

(a) Specifically, what gets imported with from xyz import * ?

if xyz module defines an __all__ variable, it will import all the names defined in this sequence, otherwise it will import all names, except these which start with an underscore.

Note Many libraries have sub-modules. For example the standard library urllib includes sub-modules like urllib.request, urllib.errors, urllib.response etc. A common point of confusion is that

from urllib import *

would import all these sub-modules. That is NOT the case: one needs to explicitly imports these separately with, say, from urllib.request import * etc. This incidentally is not specific to import *, plain import will not import sub-modules either (but of course, the * which is often a shorthand for "everything" may mislead people in thinking that all sub-modules and everything else would be imported).

`from ... import` vs `import .`

It depends on how you want to access the import when you refer to it.

from urllib import request
# access request directly.
mine = request()

import urllib.request
# used as urllib.request
mine = urllib.request()

You can also alias things yourself when you import for simplicity or to avoid masking built ins:

from os import open as open_
# lets you use os.open without destroying the 
# built in open() which returns file handles.

Use 'import module' or 'from module import'?

The difference between import module and from module import foo is mainly subjective. Pick the one you like best and be consistent in your use of it. Here are some points to help you decide.

import module

Pros:
- Less maintenance of your import statements. Don't need to add any additional imports to start using another item from the module
Cons:
- Typing module.foo in your code can be tedious and redundant (tedium can be minimized by using import module as mo then typing mo.foo)

from module import foo

Pros:
- Less typing to use foo
- More control over which items of a module can be accessed
Cons:
- To use a new item from the module you have to update your import statement
- You lose context about foo. For example, it's less clear what ceil() does compared to math.ceil()

Either method is acceptable, but don't use from module import *.

For any reasonable large set of code, if you import * you will likely be cementing it into the module, unable to be removed. This is because it is difficult to determine what items used in the code are coming from 'module', making it easy to get to the point where you think you don't use the import any more but it's extremely difficult to be sure.

from ... import OR import ... as for modules

Assuming that bar is a module or package in foo, there is no difference^*, it doesn't matter. The two statements have exactly the same result:

>>> import os.path as path
>>> path
<module 'posixpath' from '/Users/mj/Development/venvs/stackoverflow-2.7/lib/python2.7/posixpath.pyc'>
>>> from os import path
>>> path
<module 'posixpath' from '/Users/mj/Development/venvs/stackoverflow-2.7/lib/python2.7/posixpath.pyc'>

If bar is not a module or package, the second form will not work; a traceback is thrown instead:

>>> import os.walk as walk
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named walk

^* In Python 3.6 and before, there was a bug with the initialization ordering of packages containing other modules, where in the loading stage of the package using import contained.module.something as alias in a submodule would fail where from contained.module import something as alias would not. See Imports in __init__.py and `import as` statement for a very illustrative example of that problem, as well as Python issues #23203 and #30024.

Why is import * bad?

Because it puts a lot of stuff into your namespace (might shadow some other object from previous import and you won't know about it).
Because you don't know exactly what is imported and can't easily find from which module a certain thing was imported (readability).
Because you can't use cool tools like pyflakes to statically detect errors in your code.

python import module from a package

Short answer

So what does the from packages import * really mean inside that __init__.py?

The __init__.py imports itself.

Explanation

You can only import modules, not packages. Packages are just containers for modules or sub-packages. When you "import" a package you actually import the module __init__.py.

The __init__.py with this content:

from packages import mod

imports the module mod into __init__.py. Therefore, it will be available
in your main.py via packages.mod (remember packages is represented by __init__.py).

When you change the content of __init__.py to:

from packages import *

You are importing the module __init__.py, the very same file you are in.
This works (a second import just triggers a lookup in sys.modules)
but won't give you the content of mod.

This means, you can use:

from module import *

but you cannot sensibly use this with an empty __init__.py:

from package import *

Because package is actually represented by the __init__.py and there
is nothing in it yet. You can check this (interactively or in file):

>>> import packages
>>> print(packages)
<module 'packages' from '/.../packages/__init__.py'>

In __init__.py you can write:

from packages.mod import *

and then in main.py:

print packages.hello()

works. Because the function hello() is now in the global name space of the
file __init__.py.

As mentioned in the answer by mozman, you can use __all__ in __init__.py to
list the modules that should be imported if from packages import * is used. This is designed for this case.

The __init__.py has only this content:

__all__ = ['mod']

Now you can do this in main.py:

from packages import *

print mod.hello()

If you extend your __init__.py:

__all__ = ['mod']

from packages import *

You can do this in main.py:

import packages

print packages.mod.hello()

But if you remove the from packages import * from __init__.py:

__all__ = ['mod']

You will get an error:

AttributeError: 'module' object has no attribute 'mod'

because the __all__ is only used for the from packages import * case.
Now we are back to the __init__.py imports itself.

How does Python importing exactly work?

Part 1

The module is only loaded once, so there is no performance loss by importing it again. If you actually wanted it to be loaded/parsed again, you'd have to reload() the module.

The first place checked is sys.modules, the cache of all modules that have been imported previously. ^[source]

Part 2

from foo import * imports a to the local scope. When assigning a value to a, it is replaced with the new value - but the original foo.a variable is not touched.

So unless you import foo and modify foo.a, both calls will return the same value.

For a mutable type such as a list or dict it would be different, modifying it would indeed affect the original variable - but assigning a new value to it would still not modify foo.whatever.

If you want some more detailed information, have a look at http://docs.python.org/reference/executionmodel.html:

The following constructs bind names: formal parameters to functions, import statements, class and function definitions (these bind the class or function name in the defining block), and targets that are identifiers if occurring in an assignment, for loop header, in the second position of an except clause header or after as in a with statement.

The two bold sections are the relevant ones for you: First the name a is bound to the value of foo.a during the import. Then, when doing a = 5, the name a is bound to 5. Since modifying a list/dict does not cause any binding, those operations would modify the original one (b and foo.b are bound to the same object on which you operate). Assigning a new object to b would be a binding operation again and thus separate b from foo.b.

It is also worth noting what exactly the import statement does:

import foo binds the module name to the module object in the current scope, so if you modify foo.whatever, you will work with the name in that module - any modifications/assignments will affect the variable in the module.
from foo import bar binds the given name(s) only (i.e. foo will remain unbound) to the element with the same name in foo - so operations on bar behave like explained earlier.
from foo import * behaves like the previous one, but it imports all global names which are not prefixed with an underscore. If the module defines __all__ only names inside this sequence are imported.

Part 3 (which doesn't even exist in your question :p)

The python documentation is extremely good and usually verbose - you find answer on almost every possible language-related question in there. Here are some useful links:

http://docs.python.org/reference/datamodel.html (classes, properties, magic methods, etc.) ()
http://docs.python.org/reference/executionmodel.html (how variables work in python)
http://docs.python.org/reference/expressions.html
http://docs.python.org/reference/simple_stmts.html (statements such as import, yield)
http://docs.python.org/reference/compound_stmts.html (block statements such as for, try, with)

How enclosed import works in Python

If you think through what these commands actually do, it's pretty simple.

a.py:

import b
foo = 0

b.py:

bar = 1

c.py:

import a

From c, you can't just say foo, you have to say a.foo. The same is true for every name in a—constants, variables, functions, classes, and even modules. And that includes b.

So, you can't say bar or a.bar, but you can say a.b.bar.

Now, what if you change it like this:

a.py:

from b import *
foo = 0

b.py:

bar = 1

c.py:

from a import *

What that from b import * does is take everything in b's namespace, and puts it into a's namespace, so you can directly say bar from within a. And then, when you do from a import *, that takes everything in a's namespace, and puts it into c's, so just as you can do foo, you can also do bar.

This is why you usually don't want to do from b import * anywhere except in your top-level script—because your namespaces get all merged together.

It's also why you can restrict what gets picked up by * with __all__:

a.py:

from b import *
__all__ = ['foo']
foo = 0

b.py:

bar = 1

c.py:

from a import *

Now, from c, you can do c.foo, but not c.bar.

So, a can do from b import * to implement its own features, without exposing all of b's internals to its users.

In Python, what happens when you import inside of a function?

Does it re-import every time the function is run?

No; or rather, Python modules are essentially cached every time they are imported, so importing a second (or third, or fourth...) time doesn't actually force them to go through the whole import process again. 1

Does it import once at the beginning whether or not the function is run?

No, it is only imported if and when the function is executed. 2, 3

As for the benefits: it depends, I guess. If you may only run a function very rarely and don't need the module imported anywhere else, it may be beneficial to only import it in that function. Or if there is a name clash or other reason you don't want the module or symbols from the module available everywhere, you may only want to import it in a specific function. (Of course, there's always from my_module import my_function as f for those cases.)

In general practice, it's probably not that beneficial. In fact, most Python style guides encourage programmers to place all imports at the beginning of the module file.

How to load all modules in a folder?

List all python (.py) files in the current folder and put them as __all__ variable in __init__.py

from os.path import dirname, basename, isfile, join
import glob
modules = glob.glob(join(dirname(__file__), "*.py"))
__all__ = [ basename(f)[:-3] for f in modules if isfile(f) and not f.endswith('__init__.py')]

What Exactly Does "Import *" Import