'from ... import' vs ' import.` [duplikat]

Wiele osób już wyjaśniło o import vs from, więc chcę spróbować wyjaśnić nieco bardziej pod maską, gdzie leży rzeczywista różnica.

Po pierwsze, pozwól mi wyjaśnić dokładnie, co robią podstawowe instrukcje importu.

import X

Importuje moduł X i tworzy odniesienie do tego modułu w bieżąca przestrzeń nazw. Następnie należy zdefiniować ukończoną ścieżkę modułu do dostęp do określonego atrybutu lub metody z poziomu modułu (np.: X.name lub X.attribute)

from X import *

Importuje moduł X i tworzy odniesienia do wszystkich obiektów publicznych zdefiniowane przez ten moduł w bieżącej przestrzeni nazw (czyli wszystko to nie ma nazwy zaczynającej się od _) lub jakiejkolwiek nazwy wspomniałeś.

Lub, innymi słowy, po uruchomieniu tego Oświadczenia, można po prostu użyj zwykłej (niekwalifikowanej) nazwy, aby odnosić się do rzeczy zdefiniowanych w module X. Ale X sama w sobie nie jest zdefiniowane, więc X.name nie działa. I jeśli name została już zdefiniowana, została zastąpiona przez nową wersję. I jeśli nazwa w X jest zmieniony, aby wskazać inny obiekt, Twój moduł nie zauważy.

To sprawia, że wszystkie nazwy z modułu są dostępne w lokalnej przestrzeni nazw.

Teraz zobaczmy, co się stanie, gdy zrobimy import X.Y:

>>> import sys
>>> import os.path

Sprawdź sys.modules z nazwą os i os.path:

>>> sys.modules['os']
<module 'os' from '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.pyc'>
>>> sys.modules['os.path']
<module 'posixpath' from '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.pyc'>

Sprawdź globals() i locals() przestrzeń nazw dict z nazwą os i os.path:

 >>> globals()['os']
<module 'os' from '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.pyc'>
>>> locals()['os']
<module 'os' from '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.pyc'>
>>> globals()['os.path']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'os.path'
>>>    

Z powyższego przykładu wynika, że tylko os jest dodawana do lokalnych i globalnych przestrzeni nazw. Więc powinniśmy być w stanie użyć os:

 >>> os
 <module 'os' from     
  '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.pyc'>
 >>> os.path
 <module 'posixpath' from      
 '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.pyc'>
 >>>

... ale nie path:

>>> path
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'path' is not defined 
>>>

>>> del locals()['os']
>>> os
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'os' is not defined
>>> os.path
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'os' is not defined
>>>

Spójrzmy teraz na from.

from

>>> import sys
>>> from os import path

Sprawdź sys.modules z nazwą os i os.path:

>>> sys.modules['os']
<module 'os' from '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/os.pyc'>
>>> sys.modules['os.path']
<module 'posixpath' from '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.pyc'>

Więc sys.modules wygląda tak samo, jak wtedy, gdy importowaliśmy za pomocą import name.

>>> globals()['path']
<module 'posixpath' from '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.pyc'>
>>> locals()['path']
<module 'posixpath' from '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.pyc'>
>>> globals()['os']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'os'
>>>

>>> path
<module 'posixpath' from '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.pyc'>
>>> os.path
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'os' is not defined
>>>

Usuńmy 'path' z locals ():

>>> del locals()['path']
>>> path
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'path' is not defined
>>>

Ostatni przykład użycia aliasingu:

>>> from os import path as HELL_BOY
>>> locals()['HELL_BOY']
<module 'posixpath' from '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.pyc'>
>>> globals()['HELL_BOY']
<module 'posixpath' from /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.pyc'>
>>>

I nie zdefiniowano ścieżki:

>>> globals()['path']
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
KeyError: 'path'
>>>

Jedna pułapka na używanie from

Gdy importujesz to samo name z dwóch różnych modułów:

>>> import sys
>>> from os import stat
>>> locals()['stat']
<built-in function stat>
>>>
>>> stat
<built-in function stat>

Importuj statystyki z shutil Jeszcze raz:

>>>
>>> from shutil import stat
>>> locals()['stat']
<module 'stat' from 
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/stat.pyc'>
>>> stat
<module 'stat' from 
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/stat.pyc'>
>>>

OSTATNI IMPORT WYGRA

Jest bardzo mała różnica w funkcjonalności, ale pierwsza forma jest preferencyjna, jak można to zrobić

from urllib import request, parse, error

Gdzie w drugiej postaci, która musiałaby być

import urllib.request, urllib.parse, urllib.error

Jest różnica. W niektórych przypadkach jeden z nich zadziała, a drugi nie. oto przykład: powiedzmy, że mamy następującą strukturę:

foo.py
mylib\
    a.py
    b.py

Teraz chcę zaimportować b.py na a.py. i chcę importować a.py za foo. Jak to zrobić? Dwie wypowiedzi: w a piszę:

import b

W foo.py piszę:

import mylib.a

Cóż, to wygeneruje ImportError podczas próby uruchomienia foo.py. Tłumacz złoży skargę na oświadczenie importowe w a.py (import b) mówiąc tam nie ma modułu B. więc jak można to naprawić? W takiej sytuacji zmiana instrukcji import w a na import mylib.b nie będzie działać, ponieważ a i b są zarówno w lib. Rozwiązanie tutaj (lub przynajmniej jedno rozwiązanie) polega na użyciu importu bezwzględnego:

from lib import b

Source: Python: importowanie modułu, który importuje moduł

Używasz Python3 były urllib w pakiecie. Obie formy są dopuszczalne i żadna forma importu nie jest preferowana nad drugą. Czasami, gdy jest wiele katalogów pakietów, możesz użyć poprzedniego from x.y.z.a import s

W tym konkretnym przypadku z pakietem urllib, drugim sposobem import urllib.request i użycia urllib.request jest sposób równomiernego użycia biblioteki standardowej.

W Pythonie 2.x przynajmniej nie możesz zrobić import urllib2.urlopen

Musisz zrobić from urllib2 import urlopen

Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2.urlopen
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named urlopen
>>> import urllib.request
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named request
>>>

Moja główna Skarga na import urllib.prośba jest taka, że możesz nadal odwoływać się do urllib.parse, mimo że nie jest importowany.

>>> import urllib3.request
>>> urllib3.logging
<module 'logging' from '/usr/lib/python2.7/logging/__init__.pyc'>

Również prośba o mnie jest pod urllib3. Python 2.7.4 ubuntu