替代方案、灵感和比较
是什么启发了 **Typer**，它与其他替代方案相比如何，以及它从它们中学到了什么。
简介¶
如果没有他人的先前工作，**Typer** 将不存在。
之前已经创建了许多工具，这些工具帮助激发了它的创建。
以前的工具¶
argparse¶
argparse 是 Python 标准库中用于编写 CLI 的模块。
它提供了一个比将CLI 参数作为str的list读取并手动解析所有内容更好的替代方案。
启发了 **Typer** 来
提供比手动阅读CLI 参数更好的开发体验。
Hug¶
Hug 是一个用于创建 API 和 CLI 的库，它使用函数中的参数来声明所需的数据。
它启发了FastAPI和Typer中的许多想法。
启发了 **Typer** 来
使用函数参数来声明CLI 参数和CLI 选项，因为它简化了开发体验。
Plac¶
Plac 是另一个使用函数中的参数创建 CLI 的库，类似于 Hug。
启发了 **Typer** 来
提供一种简单的方法将函数用作命令行应用程序，而无需创建完整的应用程序，使用typer.run(some_function)。
Pydantic¶
Pydantic 是一个使用标准现代 Python 类型注释处理数据验证的库。
它为FastAPI提供底层支持。
它没有被Typer使用，但它启发了设计中的许多方面（通过FastAPI）。
启发了 **Typer** 来
使用标准 Python 类型注释来声明类型，而不是库特定的类型或类，并将其用于数据验证和文档。
Click¶
Click 是 Python 中最广泛使用的创建 CLI 的库之一。
它是一个非常强大的工具，并且有很多 CLI 是用它构建的。它是Typer的底层支持库。
它也使用带有参数的函数来表示CLI 参数和CLI 选项，但特定CLI 参数、CLI 选项、类型等的声明是在函数顶部的装饰器中完成的。这需要一些代码重复（例如，CLI 选项名称--verbose和变量名称verbose）以及与同一信息相关的两个地方之间的同步（装饰器和参数函数）。
它使用函数顶部的装饰器来修改这些函数的实际值，将它们转换为特定类的实例。这是一个巧妙的技巧，但代码编辑器无法以这种方式提供良好的自动完成支持。
它是在当时语言（Python 2.x）提供的功能基础上，结合了一些很棒的想法和设计而构建的。
Typer 使用它来
做所有事情。🚀
Typer 主要是在 Click 之上添加了一层，使代码更简洁易用，并提供随处可见的自动补全等功能，但同时保留了 Click 的所有强大功能。
正如有人指出的那样："很高兴看到它基于 Click 构建，但添加了类型相关的东西。我喜欢！"
click-completion¶
click-completion 是 Click 的一个插件。它最初是为了扩展 Click 在仅支持 Bash 自动补全的情况下对 shell 的自动补全支持而创建的。
Typer 的早期版本与 click-completion 深度集成，并将其作为可选依赖项。但现在所有自动补全逻辑都在 Typer 本身内部实现，内部逻辑在很大程度上借鉴了 click-completion 并使用了一些其部分代码。
现在 Typer 进行了改进，增加了新功能、测试、一些错误修复（针对普通 click-completion 和 Click 中的问题），以及对 shell 的更好支持，包括现代版本的 PowerShell（例如 Windows 10 中的默认版本）。
启发了 **Typer** 来
为所有 shell 提供自动补全功能。
FastAPI¶
我创建了 FastAPI，以提供一种简单的方法来构建 API，并为代码中的所有内容（以及一些其他功能）提供自动补全功能。
Typer 是“CLI 的 FastAPI”。
它尽可能地使用 FastAPI 的相同设计和用法。因此，如果您使用过 FastAPI，您就知道如何使用 Typer。