Summarize Python import

I'm addicted to it many times, so I'll study and learn it by carving it in my head.

Premise

Verification environment

• All execution is done by starting the REPL with the same path as the path where the tree command was executed.
• Python is 2.7.5

What is a package?

• In Python, the directory containing __init__.py is called a package.
• Basically, you need __init__.py because you don't recursively search for modules in just a directory.

Range to search when loading

1. Same directory as the execution directory

• Current directory
• Directories listed in the environment variable "PYTHONPATH"
• Directories included in sys.path

sys.path is a string list of absolute paths, which can be checked by methods such as ʻimport sys; print sys.path`.

Illustration

Import methods in the same directory

$ tree --charset=C
.
`-- greeting.py

greeting.py

def daytime():
    print 'hey'

REPL

>>> import greeting

>>> greeting.daytime() #Call
hey

Understand what you imported

REPL

>>> import greeting

>>> print type(greeting)         #The imported greeting seems to be an object called module
<type 'module'>

>>> print dir(greeting)          #You can see that it has a daytime attribute (partially omitted)
['__builtins__', ..., 'daytime']

>>> greeting.daytime()           #When calling
hey

>>> print type(greeting.daytime) #What I called seems to be an object called function
<type 'function'>

Write using from

REPL

>>> from greeting import daytime

>>> daytime()                    #Call
hey

Understand what you imported from

Let's understand what was ʻimport using from`

REPL

>>> from greeting import daytime

>>> print type(daytime)          #The daytime imported in this way seems to be an object called function
<type 'function'>

>>> print dir(daytime)           #There are no attributes defined by myself (some are omitted)
['__call__', ..., 'func_name']

>>> daytime()                    #When calling
hey

>>> print type(daytime)          #What you called is the same as what you imported
<type 'function'>

Organize

Looking at these two examples, we can see that the following two refer to the same thing.

• The daytime attribute of the greeting in the example that does not use from
• daytime in the example using from

REPL

>>> import greeting

>>> print type(greeting.daytime)
<type 'function'>


>>> from greeting import daytime

>>> print type(daytime)
<type 'function'>

Both are function objects, so you can call them with parentheses.

REPL

>>> import greeting

>>> greeting.daytime()
hey


>>> from greeting import daytime

>>> daytime()
hey

Import the methods of the package in the same directory

Now that you know the module and function objects, try importing another package

$ tree --charset=C
.
`-- subdir
    `-- greeting.py

REPL

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

As mentioned at the beginning, subdir will not be recognized as a package unless you put __init__.py.

$ touch subdir/__init__.py

once again

REPL

>>> import subdir

>>> print dir(subdir)             #But there is no greeting attribute
['__builtins__', ..., '__path__']

Apparently, even if you import the package, not all the included files can be used without permission. If you want to import greeting, you need to import ** subdir greeting **

REPL

>>> import subdir.greeting

>>> subdir.greeting.daytime()
hey

Understand what you imported

It was a little long introductory, but all I did was ʻimport subdir.greeting` Now I want to understand this

REPL

>>> import subdir.greeting

>>> print type(subdir.greeting)         #After all imported is a module object
<type 'module'>

>>> print dir(subdir.greeting)          #Has a daytime attribute
['__builtins__', ..., 'daytime']

>>> subdir.greeting.daytime()           #So you can call it like this
hey

>>> print type(subdir.greeting.daytime) #And what I called is a function object
<type 'function'>

Write using from

Considering that I was able to write ʻimport greeting as from greeting import daytime, It seems good to think of writing a module` object in from So you can write the following

REPL

>>> from subdir import greeting  #Write module in from part

>>> greeting.daytime()           #Can be called like this
hey

Also, from can be written by concatenating module according to the hierarchical structure.

REPL

>>> from subdir.greeting import daytime  #Write by concatenating module to from part

>>> daytime()                            #Can be called like this
hey

Understand what you imported from

I feel like I can understand it somehow, but I also want to understand this example.

REPL

>>> from subdir import greeting

>>> print type(greeting)          #The imported one is a module object
<type 'module'>

>>> print dir(greeting)           #Because it has a daytime attribute
['__builtins__', ..., 'daytime']

>>> greeting.daytime()            #Can be called like this
hey

>>> print type(greeting.daytime)  #What I called is a function object
<type 'function'>

REPL

>>> from subdir.greeting import daytime

>>> print type(daytime)                  #This is a function object that was imported
<type 'function'>

>>> daytime()                            #Can be called like this
hey

>>> print type(daytime)                  #What you called is the same as what you imported
<type 'function'>

Organize

I've tried about 5 examples so far, but all the executed objects are function objects. If what you importedismodule, you have the function attribute If what you import is function, you can call that function object.

So the three examples below all point to the same thing

REPL

>>> import subdir.greeting
>>> print type(subdir.greeting.daytime)
<type 'function'>

>>> from subdir import greeting
>>> print type(greeting.daytime)
<type 'function'>

>>> from subdir.greeting import daytime
>>> print type(daytime)
<type 'function'>

Import classes in the same directory

The examples so far have been methods, but I also want to understand what happens with classes.

$ tree --charset=C
.
`-- person.py

person.py

class Person():
    def daytime(self):
        print 'hey'

REPL

>>> import person

>>> person.Person().daytime()
hey

Understand what you imported

It was easy if I could understand so far

REPL

>>> import person

>>> print type(person)                 #Familiar module object
<type 'module'>

>>> print dir(person)                  #Has Person attribute
['Person', ..., '__package__']

>>> print type(person.Person)          #Unlike the method, it seems to be an object called classobj
<type 'classobj'>

>>> print dir(person.Person)           #Has a daytime attribute
['__doc__', ..., 'daytime']

>>> person.Person().daytime()          #Since it is a class, it is called after instantiating it.
hey

>>> print type(person.Person.daytime)  #Unlike function, it seems to be called instance method (static method is omitted because it is a class story)
<type 'instancemethod'>

Write using from

REPL

>>> from person import Person

>>> Person().daytime()
hey

I think there are many cases where the file name and class name are the same That's why the import statement from xxx Import Xxx appears frequently.

Understand what you imported from

I think I already understand it, but for the time being

REPL

>>> from person import Person

>>> print type(Person)          #After all it is a classobj object
<type 'classobj'>

>>> print type(Person.daytime)  #Because the daytime attribute you have is instancemethod
<type 'instancemethod'>

>>> Person().daytime()          #Can be called like this
hey

Organize

It seems that there is no big difference if you understand the case of classes and the case of methods. It seems that you only have to handle classobj instead of function

Summary

What to import and what to use

Method

REPL

>>> import greeting              #Import the file name

>>> print type(greeting)         #The imported one is module
<type 'module'>

>>> print type(greeting.daytime) #The methods that can actually be used are function
<type 'function'>

class

REPL

>>> import person                #Import the file name

>>> print type(person)           #The imported one is module
<type 'module'>

>>> print type(person.Person)    #The class that can actually be used is classobj
<type 'classobj'>

What you can and cannot do

If you don't use from, you can only write module in import

REPL

>>> import greeting.daytime
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named daytime    #Since daytime is a function, not a module, it is certainly a No module

>>> import person.Person
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named Person     #Since Person is also classobj, not module, it is certainly No module

From None There are two main points of import!

• The import target is module
• Must be function or classobj when using

If you use from, you can write anything in import

REPL

>>> from greeting import daytime         #import function

>>> from person import Person            #Import classobj

>>> from subdir import greeting          #Import module

>>> from subdir.greeting import daytime  #import function

However, when using from, you cannot use. For import.

REPL

>>> import subdir.greeting               #If only import.Can be used

>>> from subdir import greeting.daytime  #If there is from, import.Cannot be used
  File "<stdin>", line 1
    from subdir import greeting.daytime

bonus

Below this is likely to be under-verified or under-Pythonic.

Whether to use from or not

I write python very well, but I'm self-taught and haven't used it at work, so I don't understand the conventions. Is there something like the following as a judgment material? I think it should be unified at least for each project, but I'm not sure what to do ...

Benefits of no from

• You can use math.tan etc. without adding to the import statement one by one
• Even if there are variables with the same name such as sin and cos, they will not collide.
• Easy to understand relationships when importing various modules

REPL

>>> import math

>>> print math.sin(0)
0.0

>>> print math.cos(0)
1.0

Benefits of having from

• Short
• If the module name or package structure changes, you only need to fix from

REPL

>>> from math import sin,cos

>>> print sin(0)
0.0

>>> print cos(0)
1.0

Disadvantages due to from

REPL

>>> from os.path import join
>>> from random import shuffle

>>> join('root', 'sub')  #What module method is join? List system? Pass system?
>>> shuffle(range(100))
>>> abspath('current')   #abspath cannot be used unless it is added to import

from xxx import *

greeting.py

def morning():
    print 'hello'

def daytime():
    print 'hey'

def evening():
    print 'good night'

You can read all functions by doing the following

REPL

>>> from greeting import *

>>> print dir()
['__builtins__', ..., 'daytime', 'evening', 'morning']

However, due to the repair on the module side, hello has also been imported before I knew it. The local variable hello was overwritten, which caused a bug even though it wasn't fixed ... I think it's better to avoid from xxx import * so that it doesn't happen

By the way, you can't do it without using from If you understand that only module can be imported, I think you can make a mistake.

REPL

>>> import daytimeing.*
  File "<stdin>", line 1
    import daytimeing.*
                    ^
SyntaxError: invalid syntax

Import the module above

If it is not above the execution path

$ tree --charset=C         #REPL starts here
.
`-- lib
    |-- __init__.py
    |-- commons.py         <-.
    `-- util                 |
        |-- __init__.py      |
        `-- listutils.py   --'

lib/commons.py

def commons():
    print 'commons'

lib/util/listutils.py

from .. import commons

def listutils():
    commons.commons()
    print 'list utils'

REPL

>>> import lib.util.listutils

>>> lib.util.listutils.listutils()
commons
list utils

By writing .. in from, you can write the relative path to the top of the module. ** However, it cannot be specified above the executed path ** Check with the following example

When it is above the execution path

$ tree --charset=C ..
..
|-- __init__.py
|-- lib.py             <---.
`-- main               ----'  #REPL starts here

Python:../lib.py

def lib():
    print 'lib'

REPL

>>> from .. import lib
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Attempted relative import in non-package

It seems that from .. import xxx cannot be done if it is above the execution path. Strictly speaking, I think it's no good above sys.path So if you really want to import it, just add sys.path

REPL

>>> import sys

>>> sys.path.append('..')                             # sys.add path

>>> from .. import lib                                # from ..It does not mean that you will be able to do it
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Attempted relative import in non-package

>>> import lib                                        #You will be able to import lib

>>> lib.lib()
lib

Search for packages under sys.path (or something) I think it's okay if you understand that

However, if you add sys.path and forcibly import other modules The importer may not be able to grasp it, Above all, I think that the package structure is strange, so I strongly think that it should not be done personally

The end

The number of lines has become tremendous! I found a gap for days and wrote it in various ways, so I feel that there is no overall sense of unity, but that is good.

I think it was very good to understand while checking type () and dir () You shouldn't be addicted to ʻimport` anymore ...!

I don't know what happens when I use PyCharm But I want to try it someday