Python中import library as lib与from library import有何区别？哪种是最佳实践？

核心差异对比 #

• 命名空间占用不同
  import library as lib仅会在当前作用域注册lib这一个命名，库内所有对象都需要通过lib.xxx的形式调用，不会和你自定义的同名变量/函数产生冲突。而from library import xxx会直接把xxx注入到当前作用域，如果你自己的代码里有同名对象，会直接被覆盖，导致意料之外的报错。
  举个实际例子：如果你自己定义了一个处理本地文件的open函数，执行from os import open之后，你自己的open就会被os库的同名函数覆盖，而用import os as o的话，o.open和你自定义的open可以共存，互不影响。
• 导入范围不同
  import library as lib会导入库的全部公开接口，适合需要用到库内多个功能的场景。from library import xxx支持按需导入单个/多个对象，导入阶段的内存占用会更低，但这个差异在大多数常规项目中几乎可以忽略。
• 代码可读性不同
  lib.xxx的写法可以让其他开发者一眼判断出xxx所属的依赖库，不需要翻找头部的导入列表就能快速理解代码逻辑。如果用from library import xxx导入大量对象，后期排查问题时很难快速区分某个函数是第三方库提供的还是项目内自定义的。

不同场景的最佳实践 #

优先使用import library as lib的场景 #

这是工业界生产项目的首选规范，适用场景包括：

• 导入的库有行业通用的标准别名，比如import numpy as np、import pandas as pd、import matplotlib.pyplot as plt，所有Python开发者都能快速识别别名对应的依赖。
• 你需要用到同一个库的3个及以上功能，多次写全库名会增加冗余。
• 项目规模较大、有多个协作开发者，需要尽可能降低命名冲突风险，保证代码可读性。

适合使用from library import (...)的场景 #

只有满足以下条件时推荐使用：

• 仅需要用到某个库的1-2个对象，且对象命名辨识度极高，不会和自定义代码冲突，比如from math import pi、from datetime import datetime。
• 库的子模块层级非常深，写全路径会大幅降低代码简洁性，比如from django.db.models import Model，比每次写全路径django.db.models.Model可读性更高。
• 编写一次性测试脚本、小型演示代码，追求简洁优先的场景。

禁止的写法 #

不要使用from library import *通配符导入，这种写法会一次性导入库的所有公开对象，完全无法预判命名冲突，除了个别库官方明确推荐该用法的特殊场景外，生产代码中绝对禁止使用。
另外不要自定义非通用别名，比如把numpy导成n，会大幅提高其他开发者的理解成本，一定要用社区公认的标准别名。

内容的提问来源于stack exchange，提问作者curiouz