PRF: #9553 调整格式

* 调整文件格式为 UNIX 格式
* 调整空白及缩进方式
* 使用中文标点符号

translated/tech/20171009 Considering Pythons Target Audience.md

@@ -1,5 +1,5 @@
 盘点 Python 的目标受众
-============================================================
+======
 
 Python 是为谁设计的？
 
@@ -22,13 +22,13 @@ Python 是为谁设计的？
 我尝试将 CPython 的使用情况分解如下，它虽然有些过于简化（注意，这些分类的界线并不是很清晰，他们仅关注于思考新软件特性和版本发布后不同因素的影响）：
 
 * 教育类：教育工作者的主要兴趣在于建模方法的教学和计算操作方面， _不会去_写或维护生产级别的软件。例如：
-    *   澳大利亚的 [数字课程][1]
-    *   Lorena A. Barba 的 [AeroPython][2]
+    * 澳大利亚的[数字课程][1]
+    * Lorena A. Barba 的 [AeroPython][2]
 * 个人级的自动化和爱好者的项目：主要的是软件，而且经常是只有软件，用户通常是写它的人。例如：
-    *   my Digital Blasphemy [图片下载器][3]
-    *   Paul Fenwick 的 (Inter)National [Rick Astley Hotline][4]
+    * my Digital Blasphemy [图片下载器][3]
+    * Paul Fenwick 的 (Inter)National [Rick Astley Hotline][4]
 * <ruby>组织<rt>organisational</rt></ruby>过程自动化：主要是软件，而且经常是只有软件，用户是为了利益而编写它的组织。例如：
-    *   CPython 的 [核心工作流工具][5]
+    * CPython 的[核心工作流工具][5]
     * Linux 发行版的开发、构建 & 发行管理工具
 * “<ruby>一劳永逸<rt>Set-and-forget</rt></ruby>” 的基础设施中：这里是软件，（这种说法有时候有些争议），在生命周期中该软件几乎不会升级，但是，在底层平台可能会升级。例如：
     * 大多数的自我管理的企业或机构的基础设施（在那些资金充足的可持续工程计划中，这种情况是让人非常不安的）
@@ -60,7 +60,7 @@ Python 是为谁设计的？
     * 大多数的运行时库和归入这一类的框架（比如，Django、Flask、Pyramid、SQL Alchemy、NumPy、SciPy、requests)
     * 适合归入这一类的许多测试和类型推断工具（比如，pytest、Hypothesis、vcrpy、behave、mypy）
     * 其它应用程序的插件（比如，Blender plugins、OpenStack hardware adapters）
-    *   本身就代表了 “Python 世界” 基准的标准库（那是一个 [难以置信的复杂][7] 的世界观）
+    * 本身就代表了 “Python 世界” 基准的标准库（那是一个[难以置信的复杂][7]的世界观）
 
 ### CPython 主要服务于哪些受众？
 
@@ -70,7 +70,7 @@ Python 是为谁设计的？
 
 把 Python 作为一种脚本语言来使用的开发者的典型特性包括：
 
-*   主要的工作单元是由一个 Python 文件组成的（或 Jupyter notebook !)，而不是一个 Python 和元数据文件的目录
+* 主要的工作单元是由一个 Python 文件组成的（或 Jupyter notebook！)，而不是一个 Python 和元数据文件的目录
 * 没有任何形式的单独的构建步骤 —— 是 _作为_ 一个脚本分发的，类似于分发一个独立的 shell 脚本的方式
 * 没有单独的安装步骤（除了下载这个文件到一个合适的位置），除了在目标系统上要求预配置运行时环境外
 * 没有显式的规定依赖关系，除了最低的 Python 版本，或一个预期的运行环境声明。如果需要一个标准库以外的依赖项，他们会通过一个环境脚本去提供（无论是操作系统、数据分析平台、还是嵌入 Python 运行时的应用程序）
@@ -95,13 +95,13 @@ Python 是为谁设计的？
 
 ### 这些相关问题的原因是什么？
 
-这篇文章很大程度上是受 Twitter 上对 [我的这个评论][20] 的讨论鼓舞的，它援引了定义在 [PEP 411][21] 中<ruby>临时<rt>Provisional</rt></ruby> API 的情形，作为一个开源项目的例子，对用户发出事实上的邀请，请其作为共同开发者去积极参与设计和开发过程，而不是仅被动使用已准备好的最终设计。
+这篇文章很大程度上是受 Twitter 上对[我的这个评论][20]的讨论鼓舞的，它援引了定义在 [PEP 411][21] 中<ruby>临时<rt>Provisional</rt></ruby> API 的情形，作为一个开源项目的例子，对用户发出事实上的邀请，请其作为共同开发者去积极参与设计和开发过程，而不是仅被动使用已准备好的最终设计。
 
 这些回复包括一些在更高级别的库中支持临时 API 的困难程度的一些沮丧性表述、没有这些库做临时状态的传递、以及因此而被限制为只有临时 API 的最新版本才支持这些相关特性，而不是任何早期版本的迭代。
 
-我的 [主要回应][22] 是，建议开源提供者应该强制实施有限支持，通过这种强制的有限支持可以让个人的维护努力变得可持续。这意味着，如果对临时 API 的老版本提供迭代支持是非常痛苦的，到那时，只有在项目开发人员自己需要、或有人为此支付费用时，他们才会去提供支持。这与我的这个观点是类似的，那就是，志愿者提供的项目是否应该免费支持老的、商业性质的、长周期的 Python 版本，这对他们来说是非常麻烦的事，我[不认为他们应该去做][23]，正如我所期望的那样，大多数这样的需求都来自于管理差劲的、习以为常的惯性，而不是真正的需求（真正的需求，应该去支付费用来解决问题）。
+我的[主要回应][22]是，建议开源提供者应该强制实施有限支持，通过这种强制的有限支持可以让个人的维护努力变得可持续。这意味着，如果对临时 API 的老版本提供迭代支持是非常痛苦的，到那时，只有在项目开发人员自己需要、或有人为此支付费用时，他们才会去提供支持。这与我的这个观点是类似的，那就是，志愿者提供的项目是否应该免费支持老的、商业性质的、长周期的 Python 版本，这对他们来说是非常麻烦的事，我[不认为他们应该去做][23]，正如我所期望的那样，大多数这样的需求都来自于管理差劲的、习以为常的惯性，而不是真正的需求（真正的需求，应该去支付费用来解决问题）。
 
-而我的[第二个回应][24]是去实现这一点，尽管多年来一直在讨论这个问题（比如，在上面链接中最早在 2011 年的一篇的文章中，以及在 Python 3 问答的回复中的 [这里][25]、[这里][26]、和[这里][27]，以及去年的这篇文章 [Python 包生态系统][28] 中也提到了一些)，但我从来没有真实地尝试直接去解释它在标准库设计过程中的影响。
+而我的[第二个回应][24]是去实现这一点，尽管多年来一直在讨论这个问题（比如，在上面链接中最早在 2011 年的一篇的文章中，以及在 Python 3 问答的回复中的[这里][25]、[这里][26]、和[这里][27]，以及去年的这篇文章 [Python 包生态系统][28]中也提到了一些)，但我从来没有真实地尝试直接去解释它在标准库设计过程中的影响。
 
 如果没有这些背景，设计过程中的一部分，比如临时 API 的引入，或者是<ruby>受启发而不同于它<rt>inspired-by-not-the-same-as</rt></ruby>的引入，看起来似乎是完全没有意义的，因为他们看起来似乎是在尝试对 API 进行标准化，而实际上并没有。
 
@@ -109,26 +109,26 @@ Python 是为谁设计的？
 
 提交给 python-ideas 或 python-dev 的 _任何_ 建议所面临的第一个门槛就是清楚地回答这个问题：“为什么 PyPI 上的一个模块不够好？”。绝大多数的建议都在这一步失败了，为了通过这一步，这里有几个常见的话题：
 
-*   与其去下载一个合适的第三方库，新手一般可能更倾向于从互联网上 “复制粘贴” 错误的指导。（比如，这就是为什么存在 `secrets` 库的原因：它使得人们很少去使用 `random` 模块，由于安全敏感的原因，它预期用于游戏和统计模拟的）
-*   这个模块是打算去提供一个实现的参考，并允许与其它的相互竞争的实现之间提供互操作性，而不是对所有人的所有事物都是必要的。（比如，`asyncio`、`wsgiref`、`unittest`、和 `logging` 全部都是这种情况）
-*   这个模块是预期用于标准库的其它部分（比如，`enum` 就是这种情况，像`unittest`一样）
-*   这个模块是被设计去支持语言之外的一些语法（比如，`contextlib`、`asyncio` 和 `typing` 模块，就是这种情况）
-*   这个模块只是普通的临时的脚本用途（比如，`pathlib` 和 `ipaddress` 就是这种情况）
-*   这个模块被用于一个教育环境（比如，`statistics` 模块允许进行交互式地探索统计的概念，尽管你可能根本就不会用它来做全部的统计分析）
+* 与其去下载一个合适的第三方库，新手一般可能更倾向于从互联网上 “复制粘贴” 错误的指导。（比如，这就是为什么存在 `secrets` 库的原因：它使得人们很少去使用 `random` 模块，由于安全敏感的原因，它预期用于游戏和统计模拟的）
+* 这个模块是打算去提供一个实现的参考，并允许与其它的相互竞争的实现之间提供互操作性，而不是对所有人的所有事物都是必要的。（比如，`asyncio`、`wsgiref`、`unittest`、和 `logging` 全部都是这种情况）
+* 这个模块是预期用于标准库的其它部分（比如，`enum` 就是这种情况，像 `unittest` 一样）
+* 这个模块是被设计去支持语言之外的一些语法（比如，`contextlib`、`asyncio` 和 `typing` 模块，就是这种情况）
+* 这个模块只是普通的临时的脚本用途（比如，`pathlib` 和 `ipaddress` 就是这种情况）
+* 这个模块被用于一个教育环境（比如，`statistics` 模块允许进行交互式地探索统计的概念，尽管你可能根本就不会用它来做全部的统计分析）
 
 通过前面的 “PyPI 是不是明显不够好” 的检查，一个模块还不足以确保被接收到标准库中，但它已经足以转变问题为 “在接下来的几年中，你所推荐的要包含的库能否对一般的入门级 Python 开发人员的经验有所提升？”
 
-标准库中的 `ensurepip` 和 `venv` 模块的引入也明确地告诉再分发者，我们期望的 Python 级别的打包和安装工具在任何平台的特定分发机制中都予以支持。
+标准库中的 `ensurepip` 和 `venv` 模块的引入也明确地告诉再分发者，我们期望的 Python 级别的打包和安装工具在任何平台的特定分发机制中都予以支持。
 
 ### 当添加它们到标准库中时，为什么一些 API 会被改变？
 
 现在已经存在的第三方模块有时候会被批量地采用到标准库中，在其它情况下，实际上添加的是吸收了用户对现有 API 体验之后，进行重新设计和重新实现的 API，但是，会根据另外的设计考虑和已经成为其中一部分的语言实现参考来进行一些删除或细节修改。
 
-例如，不像广受欢迎的第三方库的前身 `path.py`，`pathlib` 并_没有_定义字符串子类，而是以独立的类型替代。作为解决文件互操作性问题的结果，定义了文件系统路径协议，它允许使用文件系统路径的接口去使用更多的对象。
+例如，不像广受欢迎的第三方库的前身 `path.py`，`pathlib` 并 _没有_ 定义字符串子类，而是以独立的类型替代。作为解决文件互操作性问题的结果，定义了文件系统路径协议，它允许使用文件系统路径的接口去使用更多的对象。
 
-为了在“IP 地址” 这个概念的教学上提供一个更好的工具，为 `ipaddress` 模块设计的 API，将地址和网络的定义调整为显式的、独立定义的主机接口（IP 地址被关联到特定的 IP 网络)，而最原始的 `ipaddr` 模块中，在网络术语的使用方式上不那么严格。
+为了在“IP 地址” 这个概念的教学上提供一个更好的工具，为 `ipaddress` 模块设计的 API，将地址和网络的定义调整为显式的、独立定义的主机接口（IP 地址被关联到特定的 IP 网络)，而最原始的 `ipaddr` 模块中，在网络术语的使用方式上不那么严格。
 
-另外的情况是，标准库将综合多种现有的方法的来构建，以及为早已存在的库定义 API 时，还有可能依靠不存在的语法特性。比如，`asyncio` 和 `typing` 模块就全部考虑了这些因素，虽然在 PEP 557 中正在考虑将后者所考虑的因素应用到 `dataclasses` API 上。（它可以被总结为 “像属性一样，但是使用可变注释作为字段声明”）。
+另外的情况是，标准库将综合多种现有的方法的来构建，以及为早已存在的库定义 API 时，还有可能依靠不存在的语法特性。比如，`asyncio` 和 `typing` 模块就全部考虑了这些因素，虽然在 PEP 557 中正在考虑将后者所考虑的因素应用到 `dataclasses` API 上。（它可以被总结为 “像属性一样，但是使用可变注释作为字段声明”）。
 
 这类改变的原理是，这类库不会消失，并且它们的维护者对标准库维护相关的那些限制通常并不感兴趣（特别是，相对缓慢的发行节奏）。在这种情况下，在标准库文档的更新版本中，很常见的做法是使用 “See Also” 链接指向原始模块，尤其是在第三方版本提供了额外的特性以及标准库模块中忽略的那些特性时。
 
@@ -142,13 +142,13 @@ Python 是为谁设计的？
 
 ### 为什么只有一些标准库 API 被升级？
 
-这里简短的回答得到升级的主要 API 有哪些？：
+这里简短的回答得到升级的主要 API 有哪些：
 
 * 不太可能有大量的外部因素干扰的附加更新
 * 无论是对临时脚本使用案例还是对促进将来多个第三方解决方案之间的互操作性，都有明显好处的
 * 对这方面感兴趣的人提交了一个可接受的建议
 
-如果一个用于应用程序开发的模块存在一个非常明显的限制，比如，`datetime`，如果重分发者通过可供替代的第三方选择很容易地实现了改善，比如，`requests`，或者，如果标准库的发布节奏与所需要的包之间真的存在冲突，比如，`certifi`，那么，建议对标准库版本进行改变的因素将显著减少。
+如果一个用于应用程序开发的模块存在一个非常明显的限制，比如 `datetime`，如果重分发者通过可供替代的第三方选择很容易地实现了改善，比如 `requests`，或者，如果标准库的发布节奏与所需要的包之间真的存在冲突，比如 `certifi`，那么，建议对标准库版本进行改变的因素将显著减少。
 
 从本质上说，这和上面的关于 PyPI 问题正好相反：因为，从应用程序开发人员体验改善的角度来说，PyPI 分发机制通常 _是_ 足够好的，这种分发方式的改进是有意义的，允许重分发者和平台提供者自行决定将哪些内容作为他们缺省提供的一部分。
 
@@ -156,9 +156,9 @@ Python 是为谁设计的？
 
 ### 标准库任何部分都有独立的版本吗？
 
-是的，它就像是 `ensurepip` 使用的捆绑模式（CPython 发行了一个 `pip` 的最新捆绑版本，而并没有把它放进标准库中），将来可能被应用到其它模块中。
+是的，它就像是 `ensurepip` 使用的捆绑模式（CPython 发行了一个 `pip` 的最新捆绑版本，而并没有把它放进标准库中），将来可能被应用到其它模块中。
 
-最有可能的第一个候选者是 `distutils` 构建系统，因为切换到这种模式将允许构建系统在多个发行版本之间保持一致。
+最有可能的第一个候选者是 `distutils` 构建系统，因为切换到这种模式将允许构建系统在多个发行版本之间保持一致。
 
 这种处理方式的其它的可能候选者是 Tcl/Tk 图形捆绑和 IDLE 编辑器，它们已经被拆分，并且通过一些重分发程序转换成可选安装项。
 
@@ -174,7 +174,7 @@ Python 是为谁设计的？
 
 这篇文章不是为了说，我们在开发 CPython 过程中从来没有做出过不正确的决定 —— 它只是去合理地回应那些对添加到 Python 标准库中的看上去很荒谬的特性的质疑，它将是 “我不是那个特性的预期目标受众的一部分”，而不是 “我对它没有兴趣，因此它对所有人都是毫无用处和没有价值的，添加它纯属骚扰我”。
 
---------------------------------------------------------------------------------
+---
 
 via: http://www.curiousefficiency.org/posts/2017/10/considering-pythons-target-audience.html