Python包导入

Question

我想知道为什么我们使用from module import module

例如，from BeautifulSoup import BeautifulSoup而不是import BeautifulSoup。

这两者都不一样吗？

如果是，那怎么做？

Answer 1

是的，它们是不同的。

有几种导入模块的方法

1. import module 模块是导入的，但是它的所有函数、类和变量都保留在“模块”的名称空间内。要引用它们，必须加上模块名： module.somefunction() module.someclass() module.somevariable = 1
2. import module as md 模块是导入的，但给出了一个新的名称空间'md‘。要引用函数、类和变量，它们必须加上新的命名空间： md.somefunction() module.someclass() module.somevariable = 1 这使名称空间保持分隔，但提供了一个简写符号，使代码更具可读性。
3. from module import * 模块中的所有函数、类和变量都被导入到当前命名空间中，就好像它们是在当前模块中定义的一样。他们可以用自己的名字来称呼： somefunction() someclass() somevariable = 1 缺点是可能有重叠的名称！
4. from module import something from module import something, somethingelse 这只会将一个函数、一个类和一个变量导入当前的命名空间中。 这不仅提高了效率，而且还降低了重叠名称的风险。

模块名称和模块内部的类可能具有相同的名称。别让这把你弄糊涂了

import BeautifulSoup参考：BeautifulSoup.BeautifulSoup()

from BeautifulSoup import BeautifulSoup参考：BeautifulSoup()

import BeautifulSoup as bs参考：bs.BeautifulSoup()

Answer 2

我认为这可以归结为个人库(Python )所有者想要做的事情，但是他们认为人们使用他们的产品是最容易的。作为Python社区的一部分，它们可能会考虑到当前的约定。这些可以正式地作为佩普 (如PEP 8 )、通过普通实践非正式地进行，也可以作为第三方形式化指针来完成。

可能会令人困惑的是，有一些区别，比如package模块，有可能帮助理解，但对Python应用程序本身并不意味着什么。例如，在您的示例中，它不是from module import module；它更像用于BeautifulSoup的from package import class。但是可以说，包是一个外部模块。我听说过一些人称任何文件为模块，而将任何目录称为包。

更多背景，如果您对python还不熟悉的话：

在python中，所有这些都是关于名称空间的。与以前的语言相比，Namespacing具有允许非常干净和灵活的代码组织的潜力。但是，它也允许任何包、模块、类、函数、方法、变量或其他名称都很难让编写客户端应用程序的人知道什么是什么。在标准库中甚至有一个用于伪造它的方便类：types.Namespace。其次是元类和动态规划。无论如何，为了减少混乱，遵循一些共同的惯例，但它们必须与语言本身分开学习(比如学习一个国家的风俗，而不仅仅是它的语言，以便能够理解共同的短语)。

关于名称空间，佩普20必须说什么：

import this

回到PEP 8，通常认为类是没有下划线的单词大写(class SomeClass:)，而函数、变量和方法都是小写的，单词由下划线(some_variable)分隔。并非总是如此，但这些可能是最广泛接受的风格。在某些地方，我看到了一些与"pythonic“和/或常见的东西相反的东西:绑定库是来自另一种语言的库的薄包装器(例如C++)，或者是当Python代码与另一种语言中的代码紧密耦合时，所以样式为了更容易的转换而模糊在一起。没有人说任何人都必须遵循特定的风格。

有些人更喜欢简洁，所以他们可以缩短和组合变量名称的单词(例如，foo bar作为fb)。其他人可能喜欢显式(例如，foo bar作为foo_bar)。还有一些人可能更喜欢泛化，用注释来描述他们的变量(为什么？(对于大型复方程来说可能很方便)：

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

有些人非常喜欢遵循非常严格的规则的黑色这样的格式化者，但另一些人喜欢灵活性，或者有理由违背惯例。即使在Python附带的标准库中，遗留代码也存在不一致之处，在社区确定代码所违背的通用实践之前，这些代码是由维护人员单独保留或允许的。