如果你刚开始接触开源，那么下面的 2020 年十篇好文章有助于指导你的发展之路。

我们存在的意义是为了向世界宣传开源的一切，从新工具到框架拓展到社区。我们的目标是让想要使用开源或为开源做贡献的人更容易参与其中。

入门开源可能很难，所以我们定期分享如何参与其中的提示和建议。如果你想要学习 Python，帮助抗击 COVID-19，或者加入 K8s 设置，我们将为你服务。

为了帮助你开始，我们总结了 2020 年发布的 10 篇最流行的开源入门文章。希望它们能激发你在 2021 年学习一些新知识。

《利用 Python 爬取网站的新手指南》

你是否想通过实践而不是阅读来学习 Python？在本教程中，Julia Piaskowski 将会指导你完成她的第一个Python 网页爬取项目。她具体展示了如何使用 Python 的 requests 库访问网页内容。

Julia 详细介绍了每一步，从安装 Python3 到使用 Pandas 来清理 Web 抓取结果。她利用了大量截图解释了如何以最终目标为目的进行爬取。

有关爬取相关内容的部分特别有用；当遇到困难处时，她会详细解释。但是，与本文的其余部分一样，她会指导你完成每个步骤。

《在 Linux 上使用 SSH 进行远程连接的初学者指南》

如果你之前从未使用过安全 shell（SSH），那么你在第一次使用时可能会感到困惑。在本教程中，Seth Kenlon 展示了如何为两台计算机之间配置 SSH 连接，以及如何不使用密码而安全地进行连接。

Seth 解释了建立 SSH 连接的每个步骤，从你应该了解的四个关键术语到在每个主机上激活 SSH 的步骤。他还提供了有关查找计算机 IP 地址、创建 SSH 密钥以及对远程计算机的远程访问权限的建议。

《五步学会任何编程语言》

如果你已经掌握了一种编程语言，你就能学习所有的语言。这是 Seth Kenlon 编写本文的前提，他认为了解一些基本编程逻辑便可以跨语言拓展。

Seth 分享了程序员在学习一种新的编程语言或编码方式时所需要的五种东西。语法、内置函数和解析器是这五种之一，他对每一种都附上了行动步骤。

那么将它们统一起来的关键方式是？一旦了解了代码工作原理，你就可以跨语言拓展。对你来说，没有什么是太难学的。

《为 COVID-19 贡献开源医疗项目》

你是否知道一家意大利医院通过 3D 打印机设备挽救了 COVID-19 患者的生命？这是开源贡献者为 2020 年 COVID-19 大流行建立的众多解决方案之一。

在本文中，Joshua Pearce 分享了针对 COVID-19 的开源志愿服务项目。虽然 Open Air 是最大的项目，但 Joshua 解释了如何为开源呼吸机的维基工作，编写开源 COVID-19 医疗供应要求，测试开源氧气浓缩机原型等。

《GNOME 入门建议》

GNOME 是最受欢迎的 Linux 桌面之一，但是它适合你吗？本文分享了来自 GNOME 用户的建议，以及有关此主题的文章。

想要在配置桌面上寻找一些灵感吗？本文包含了有关 GNOME 扩展入门，将 Dash 安装到 Dock，使用 GNOME Tweak 工具等的链接。

不过，你仍然可能会认为 GNOME 不适合你——不用担心，最后你将找到指向其他 Linux 桌面和窗口管理器的链接。

《现在开始为开源做贡献的 3 个理由》

截至到 2020 年 6 月，Github 托管了超过 180,000 个公共仓库。现如今加入开源社区比过去更容易，但这是否意味着你应该加入开源？在本文中，Jason Blais 分享了三个投身开源的原因。

为开源做贡献可以增强你的信心、简历和专业网络。Jason 还解释了如何利用有用的信息，从如何在领英个人资料中添加开源信息，到如何将这些贡献转变为付费角色。最后还列出了供初学者参与的出色项目。

《作为 Linux 系统管理员为开源做贡献的 4 种方法》

系统管理员是开源的无名英雄。他们在代码背后做了大量工作，这些代码非常有价值，但通常是看不见的。

在本文中，Elizabeth K. Joseph 介绍了她如何以 Linux 系统管理员的身份来改善开源项目。用户支持、托管项目资源、寻找新的网站环境是让社区比她发现时变得更好的几种方式。

也许最重要的贡献是什么？文档！Elizabeth 在开源领域的起步是她为使用的项目重写了快速入门指南。向你经常使用的项目提交错误和补丁报告是参与其中的理想方法。

《为 Slack 的开源替代品做出贡献的 6 种方法》

Mattermost 是一个很受欢迎的平台，适合那些想要一个开源消息传递系统的团队的平台。其活跃、充满活力的社区是让用户保持忠诚度的关键因素，尤其是对那些具有 Go、React 和 DevOps 经验的用户。

如果你想为 Mattermost 做出贡献，Jason Blais 具体介绍了如何参与其中。将本文视为你的入门文档：Blais 分享了你要采取的步骤，并介绍了你可以做出的六种贡献。

无论你是要构建一个集成还是本地化你的语言，本文都将介绍如何进行。

《如何为 Kubernetes 做贡献》

当我走进 2018 年温哥华青年开源峰会时，还很年轻，对 Kubernetes 一无所知。主题演讲结束后，我离开会场后依然是一个有所改变而依然困惑的女人。毫不夸张地说，Kubernetes 已经彻底改变了开源，这并不夸张：很难找到一个更受欢迎、更有影响力的项目。

如果你想做出贡献，那么 IBM 工程师 Tara Gu 介绍了她是如何开始的。本文介绍了她在 All Things Open 2019 会议上的闪电演讲的回顾以及包括她亲自演讲的视频。还记得吗？

《任何人如何在工作中为开源软件做出贡献》

需求是发明之母，尤其是在开源领域。许多人针对自己遇到的问题构建开源解决方案。但是如果开发人员在没有收集目标用户反馈的情况下通过构建产品而错过了目标，会发生什么呢？

在企业中，产品和设计团队通常会填补这一空白。如果开源团队中不存在这样的角色，开发人员应该怎么做？

在本文中，Catherine Robson 介绍了开源团队如何从目标用户那里收集反馈。它为希望与开发人员分享他们的工作经验，从而将他们的反馈贡献到开源项目的人们而编写。

Catherine 概述的步骤将帮助你与开源团队分享你的见解，并在帮助团队开发更好的产品方面发挥关键作用。

你想要学习什么？

你想了解开源入门哪些方面的知识？请在评论中分享你对文章主题的建议。同时如果你有故事可以分享，以帮助他人开始使用开源软件，请考虑撰写文章。

via: https://opensource.com/article/21/1/getting-started-open-source

作者：Lauren Maffeo 选题：lujun9972 译者：萌新阿岩 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

特斯拉可能从比特币投资中赚取了超过 6 亿美元，超过过去十年盈利

之前，特斯拉宣布购买了 15 亿美元的比特币。它没有透露其买入的比特币数量和平均买入价格。但 1 月份比特币的平均价格在 3.5 万美元左右，这意味着特斯拉应该拥有约 4.3 万个比特币。目前，比特币的交易价格接近 5.2 万美元。这意味着，如果没有卖掉的话，特斯拉拥有的比特币现在价值可能高达 22 亿美元，这可能从这笔投资中获得了超过 6 亿美元的未实现收益。

考虑到特斯拉多年来的净亏损状况，在 2020 财年才首次实现盈利，盈利额为 7.21 亿美元。特斯拉从单笔 15 亿美元的比特币购买中获得的利润，有可能比过去十年从汽车中获得的利润还要多。

这真是一盘大棋啊。

Chromebook 销量超过苹果电脑，Chrome OS 成为第二大操作系统

根据市场分析公司 IDC 的数据，Chromebook 电脑的销量超过了苹果的 Mac，而它运行的 Chrome OS 操作系统也成为第二大流行的操作系统。但苹果电脑的市场份额并没有缩小，Chromebook 主要吞食的是低端的 Windows PC 市场，这可能与疫情推动的远程教育有关。Windows 的市场份额从 2019 年的 85.4% 跌至了 2020 年的 80.5%；Chrome OS 从 6.4% 增加到 10.8%；macOS 从 6.7% 增至 7.5%。

我很想说，Linux 桌面还有指望，但是看着 Chrome OS 超越了 macOS，实在是没底气说。

因北美严寒，Linux 5.12 的合并窗口被“冻住”了

本周，美国多个州遭遇冬季寒潮，部分区域迎来罕见的低温和暴风雪，导致出现了大面积停电和停暖的现象。而令人想不到的是，Linux 内核的开发工作也因此受到了影响。Linux 5.12 是一个非常重要的版本，原本现在应该进入合并窗口，冻结新的特性提交，但没想到严寒导致的停电，反而让合并窗口“冻住”关不上了。

Linux 内核团队发布公告称，“为什么 5.12 合并窗口的拉取请求似乎还没有被执行，原因是由于美国西北太平洋地区的严冬天气造成的停电。”，而目前尚没有明确的时间表，在这一问题得到解决之前，5.12 的合并窗口将被搁置。

虽然这是一则趣闻，Linux 的开发也不会一直停滞下去，但是没想到发达的美国也会招致这些基础设施问题，从而影响了 Linux 的开发。

互联网诞生之时我的个人故事。

最近，我和大家 分享了 我在 1994 年获得英国文学和神学学位离开大学后，如何在一个人们还不知道 Web 服务器是什么的世界里成功找到一份运维 Web 服务器的工作。我说的“世界”，并不仅仅指的是我工作的机构，而是泛指所有地方。Web 那时当真是全新的 —— 人们还正尝试理出头绪。

那并不是说我工作的地方（一家学术出版社）特别“懂” Web。这是个大部分人还在用 28.8K 猫（调制解调器，俗称“猫”）访问网页的世界。我还记得我拿到 33.6K 猫时有多激动。至少上下行速率不对称的日子已经过去了， ^[1] 以前 1200/300 的带宽描述特别常见。这意味着（在同一家机构的）印刷人员制作的设计复杂、色彩缤纷、纤毫毕现的文档是完全不可能放在 Web 上的。我不能允许在网站的首页出现大于 40k 的 GIF 图片，这对我们的许多访问者来说是很难接受的。大于大约 60k 图片的会作为独立的图片，以缩略图链接过去。

如果说市场部只有这一点不喜欢，那是绝对是轻描淡写了。更糟的是布局问题。“浏览器决定如何布局文档，”我一遍又一遍地解释，“你可以使用标题或者段落，但是文档在页面上如何呈现并不取决于文档，而是取决于渲染器！”他们想控制这些，想要不同颜色的背景。后来明白了那些不能实现。我觉得我就像是参加了第一次讨论层叠样式表（CSS）的 W3C 会议，并进行了激烈地争论。关于文档编写者应控制布局的建议真令人厌恶。 ^[2] CSS 花了一些时间才被人们采用，与此同时，关心这些问题的人搭上了 PDF 这种到处都是安全问题的列车。

如何呈现文档不是唯一的问题。作为一个实体书出版社，对于市场部来说，拥有一个网站的全部意义在于，让客户（或者说潜在的客户）不仅知道一本书的内容，而且知道买这本书需要花多少钱。但这有一个问题，你看，互联网，包括快速发展的万维网，是开放的，是所有都免费的自由之地，没有人会在意钱；事实上，在那里谈钱是要回避和避免的。

我和主流“网民”的看法一致，认为没必要把价格信息放在线上。我老板，以及机构里相当多的人都持相反的意见。他们觉得消费者应该能够看到书要花多少钱。他们也觉得我的银行经理也会想看到我的账户里每个月进了多少钱，如果我不认同他们的观点的话，那我的收入就可能堪忧。

幸运的是，在我被炒鱿鱼之前，我已经自己认清了一些 —— 可能是在我开始迈入 Web 的几星期之后，Web 已经发生变化，有其他人公布他们的产品价格信息。这些新来者通常被那些从早期就开始运行 Web 服务器的老派人士所看不起， ^[3] 但很明显，风向是往那边吹的。然而，这并不意味着我们的网站就赢得了战争。作为一个学术出版社，我们和大学共享一个域名（在 “ac.uk” 下）。大学不太相信发布价格信息是合适的，直到出版社的一些资深人士指出，普林斯顿大学出版社正在这样做，如果我们不做……看起来是不是有点傻？

有趣的事情还没完。在我担任站点管理员（“webmaster@…”）的短短几个月后，我们和其他很多网站一样开始看到了一种令人担忧的趋势。某些访问者可以轻而易举地让我们的 Web 服务器跪了。这些访问者使用了新的网页浏览器：网景浏览器（Netscape）。网景浏览器实在太恶劣了，它居然是多线程的。

这为什么是个问题呢？在网景浏览器之前，所有的浏览器都是单线程。它们一次只进行一个连接，所以即使一个页面有五张 GIF 图， ^[4] 也会先请求 HTML 基本文件进行解析，然后下载第一张 GIF，完成，接着第二张，完成，如此类推。事实上，GIF 的顺序经常出错，使得页面加载得非常奇怪，但这也是常规思路。而粗暴的网景公司的人决定，它们可以同时打开多个连接到 Web 服务器，比如说，可以同时请求所有的 GIF！为什么这是个问题呢？好吧，问题就在于大多数 Web 服务器都是单线程的。它们不是设计来一次进行多个连接的。确实，我们运行的 HTTP 服务的软件（MacHTTP）是单线程的。尽管我们花钱购买了它（最初是共享软件），但我们用的这版无法同时处理多个请求。

互联网上爆发了大量讨论。这些网景公司的人以为他们是谁，能改变世界的运作方式？它应该如何工作？大家分成了不同阵营，就像所有的技术争论一样，双方都用各种技术热词互丢。问题是，网景浏览器不仅是多线程的，它也比其他的浏览器更好。非常多 Web 服务器代码维护者，包括 MacHTTP 作者 Chuck Shotton 在内，开始坐下来认真地在原有代码基础上更新了多线程测试版。几乎所有人立马转向测试版，它们变得稳定了，最终，浏览器要么采用了这种技术，变成多线程，要么就像所有过时产品一样销声匿迹了。 ^[5]

对我来说，这才是 Web 真正成长起来的时候。既不是网页展示的价格，也不是设计者能定义你能在网页上看到什么， ^[6] 而是浏览器变得更易用，以及成千上万的浏览者向数百万浏览者转变的网络效应，使天平向消费者而不是生产者倾斜。在我的旅程中，还有更多故事，我将留待下次再谈。但从这时起，我的雇主开始看我们的月报，然后是周报、日报，并意识到这将是一件大事，真的需要关注。

1. 它们又是怎么回来的？ ↩︎
2. 你可能不会惊讶，我还是在命令行里最开心。 ↩︎
3. 大约六个月前。 ↩︎
4. 莽撞，没错，但它确实发生了 ^[7] ↩︎
5. 没有真正的沉寂：总有一些坚持他们的首选解决方案具有技术上的优势，并哀叹互联网的其他人都是邪恶的死硬爱好者。 ^[8] ↩︎
6. 我会指出，为那些有各种无障碍需求的人制造严重而持续的问题。 ↩︎
7. 噢，不，是 GIF 或 BMP，JPEG 还是个好主意，但还没有用上。 ↩︎
8. 我不是唯一一个说“我还在用 Lynx”的人。 ↩︎

via: https://opensource.com/article/19/3/when-web-grew

作者：Mike Bursell 选题：lujun9972 译者：XYenChi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

AndroidXML 和 TotalCross 的运用为树莓派和其他设备创建 UI 提供了更简单的方法。

为应用程序创建良好的用户体验（UX）是一项艰巨的任务，尤其是在开发嵌入式应用程序时。今天，有两种图形用户界面（GUI）工具通常用于开发嵌入式软件：它们要么涉及复杂的技术，要么非常昂贵。

然而，我们已经创建了一个概念验证（PoC），它提供了一种新的方法来使用现有的、成熟的工具为运行在桌面、移动、嵌入式设备和低功耗 ARM 设备上的应用程序构建用户界面（UI）。我们的方法是使用 Android Studio 绘制 UI；使用 TotalCross 在设备上呈现 Android XML；采用被称为 KnowCode 的新 TotalCross API；以及使用 树莓派 4 来执行应用程序。

选择 Android Studio

可以使用 TotalCross API 为应用程序构建一个美观的响应式用户体验，但是在 Android Studio 中创建 UI 缩短了制作原型和实际应用程序之间的时间。

有很多工具可以用来为应用程序构建 UI，但是 Android Studio 是全世界开发者最常使用的工具。除了它被大量采用以外，这个工具的使用也非常直观，而且它对于创建简单和复杂的应用程序都非常强大。在我看来，唯一的缺点是使用该工具所需的计算机性能，它比其他集成开发环境 （IDE） 如 VSCode 或其开源替代方案 VSCodium 要庞大得多。

通过思考这些问题，我们创建了一个概念验证，使用 Android Studio 绘制 UI，并使用 TotalCross 直接在设备上运行 AndroidXML。

构建 UI

对于我们的 PoC，我们想创建一个家用电器应用程序来控制温度和其他东西，并在 Linux ARM 设备上运行。

我们想为树莓派开发我们的应用程序，所以我们使用 Android 的 ConstraintLayout 来构建 848x480（树莓派的分辨率）的固定屏幕大小的 UI，不过你可以用其他布局构建响应性 UI。

Android XML 为 UI 创建增加了很多灵活性，使得为应用程序构建丰富的用户体验变得容易。在下面的 XML 中，我们使用了两个主要组件：ImageView 和 TextView。

<ImageView
android:id="@+id/imageView6"
android:layout_width="273dp"
android:layout_height="291dp"
android:background="@drawable/Casa"
tools:layout_editor_absoluteX="109dp"
tools:layout_editor_absoluteY="95dp" />
<TextView
android:id="@+id/insideTempEdit"
android:layout_width="94dp"
android:layout_height="92dp"
android:background="#F5F5F5"
android:text="20"
android:textAlignment="center"
android:gravity="center"
android:textColor="#000000"
android:textSize="67dp"
android:textStyle="bold"
tools:layout_editor_absoluteX="196dp"
tools:layout_editor_absoluteY="246dp" />

TextView 元素用于向用户显示一些数据，比如建筑物内的温度。大多数 ImageView 都用作用户与 UI 交互的按钮，但它们也需要实现屏幕上组件提供的事件。

用 TotalCross 整合

这个 PoC 中的第二项技术是 TotalCross。我们不想在设备上使用 Android 的任何东西，因为：

1。我们的目标是为 Linux ARM 提供一个出色的 UI。 2。我们希望在设备上实现低占用。 3。我们希望应用程序在低计算能力的低端硬件设备上运行（例如，没有 GPU、 低 RAM 等）。

首先，我们使用 VSCode 插件 创建了一个空的 TotalCross 项目。接下来，我们保存了 drawable 文件夹中的图像副本和 xml 文件夹中的 Android XML 文件副本，这两个文件夹都位于 resources 文件夹中：

为了使用 TotalCross 模拟器运行 XML 文件，我们添加了一个名为 KnowCode 的新 TotalCross API 和一个主窗口来加载 XML。下面的代码使用 API 加载和呈现 XML：

public void initUI() {
    XmlScreenAbstractLayout xmlCont = XmlScreenFactory.create("xml / homeApplianceXML.xml");
    swap(xmlCont);
}

就这样！只需两个命令，我们就可以使用 TotalCross 运行 Android XML 文件。以下是 XML 如何在 TotalCross 的模拟器上执行：

完成这个 PoC 还有两件事要做：添加一些事件来提供用户交互，并在树莓派上运行它。

添加事件

KnowCode API 提供了一种通过 ID（getControlByID） 获取 XML 元素并更改其行为的方法，如添加事件、更改可见性等。

例如，为了使用户能够改变家中或其他建筑物的温度，我们在 UI 底部放置了加号和减号按钮，并在每次单击按钮时都会出现“单击”事件，使温度升高或降低一度：

Button plus = (Button) xmlCont.getControlByID("@+id/plus");
Label insideTempLabel = (Label) xmlCont.getControlByID("@+id/insideTempLabel");
plus.addPressListener(new PressListener() {
    @Override
    public void controlPressed(ControlEvent e) {
        try {
            String tempString = insideTempLabel.getText();
            int temp;
            temp = Convert.toInt(tempString);
            insideTempLabel.setText(Convert.toString(++temp));
        } catch (InvalidNumberException e1) {
            e1.printStackTrace();
        }
    }
});

在树莓派 4 上测试

最后一步！我们在一台设备上运行了应用程序并检查了结果。我们只需要打包应用程序并在目标设备上部署和运行它。VNC 也可用于检查设备上的应用程序。

整个应用程序，包括资源（图像等）、Android XML、TotalCross 和 Knowcode API，在 Linux ARM 上大约是 8MB。

下面是应用程序的演示：

在本例中，该应用程序仅为 Linux ARM 打包，但同一应用程序可以作为 Linux 桌面应用程序运行，在Android 设备 、Windows、windows CE 甚至 iOS 上运行。

所有示例源代码和项目都可以在 HomeApplianceXML GitHub 存储库中找到。

现有工具的新玩法

为嵌入式应用程序创建 GUI 并不需要像现在这样困难。这种概念证明为如何轻松地完成这项任务提供了新的视角，不仅适用于嵌入式系统，而且适用于所有主要的操作系统，所有这些系统都使用相同的代码库。

我们的目标不是为设计人员或开发人员创建一个新的工具来构建 UI 应用程序；我们的目标是为使用现有的最佳工具提供新的玩法。

你对这种新的应用程序开发方式有何看法？在下面的评论中分享你的想法。

via: https://opensource.com/article/20/5/linux-arm-ui

作者：Bruno Muniz 选题：lujun9972 译者：Chao-zhi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

SolarWinds 攻击至少需要有 1000 位工程师

这场长达数月的，可能影响了多达 1.8 万家美国政府机构和网络安全厂商的黑客攻击活动，是通过在 SolarWinds 的 Orion 网络管理软件内植入木马进行的软件供应链攻击。

微软总裁布拉德•史密斯在访谈中谈到，“我认为从软件工程的角度来看，可能可以说这是世界上有史以来规模最大、最复杂的攻击”。微软也是这次攻击的受害者之一，为了调查这次攻击，微软指派了 500 名工程师参与了调查。史密斯认为，“当我们分析在微软看到的一切时，我们问自己大概有多少工程师参与过这些攻击。而我们得出的答案是，肯定超过 1000 人。”

据悉，攻击者只在 Orion 内重写了 4032 行代码，而 Orion 由数百万行代码组成。

我认为，这么大规模、处心积虑的攻击行为，背后没有一个严密的组织是不可能的，不过这个规模还是令人吃惊的。

开源 Web 扩展项目中的恶意程序问题

一些广为流传的 Chrome 开源扩展在变更了控制权之后，变成了恶意软件。这包括 The Great Suspender 的所有权在去年 10 月转移给一个未公开身份的人之后，推送了恶意更新，它会下载和执行第三方 JavaScript 脚本，并关闭了自动更新机制，这意味着即使恶意代码移除现有用户仍然会继续使用恶意版本。谷歌最近决定强制移除该恶意扩展。

这样的事情并不鲜见，还包括 uBlock 转移所有权之后，被新的维护者用来牟利和让广告商付费免除屏蔽；Nano Adblocker 和 Nano Defender 也在转移后变成了恶意扩展。

用户往往不会注意也不会得到开源的扩展应用所有权转移的通知，这就为使用开源扩展带来了潜在的风险。因为，谷歌并不会对这些扩展进行事先的人工审查，而用户基于之前的口碑也往往在受到侵害后才可能发现问题。

我认为，这个问题需要得到重视，作为托管这些扩展的谷歌商店，应该建立相应的机制，最起码可以做到明确提醒所有权变更，或对刻意的更新进行更严格的审查。

谷歌在称赞其 Stadia 工作室一周后，关闭了它

谷歌在 2 月 1 日出人意料地宣布，将关闭 Stadia 游戏开发工作室。但这一消息不仅仅是对 Stadia 客户的惊吓，对于 Stadia 开发团队来说更是晴天霹雳。据报道，就在一周前，Stadia 开发团队还被告知，工作室正在取得“巨大的进步”。

据报道，谷歌副总裁、Stadia 总经理哈里森承认，当他发邮件赞扬团队的进展时，谷歌的高管们已经知道关闭的消息了。

我认为，这也太儿戏了，这些领导人说的话都是官样文章，你相信就天真了。

Python 之禅 （ Zen of Python ） 最早由 Tim Peters 于 1999 年发表于 Python 邮件列表中，它包含了影响 Python 编程语言设计的 19 条软件编写原则。在最初及后来的一些版本中，一共包含 20 条，其中第 20 条是“这一条留空（...）请 Guido 来填写”。这留空的一条从未公布也可能并不存在。

Python 之禅作为一个信息条款也被录入 Python 增强建议 （ Python Enhancement Proposals ） （PEP）的第 20 条，在 Python 语言的官方网站也能找到。

此外，关于 Python 之禅，还有一件趣事。在 2001 召开第十届国际 Python 峰会（IPC 10，Pycon 的前身）前夕，会议主办方希望定制一件 T 恤，并绞尽脑汁地从投稿的标语中选择了一条 “import this”。然后，他们决定将这个语句实现在 Python 解释器中，于是将 Python 之禅的内容进行简单加密后放入到了 Python 2.2.1 中的 this.py 库当中。如果你在 Python 的解释器中输入 import this ，就会显示出来：

>>> import this;
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

作为 Python 之禅系列文章的总结，我在下面重新整理并链接了之前的各篇文章。对于 Python 之禅的理解大家各有不同，目前也有几个不同的中文翻译版本。为了避免雷同，我们在翻译这系列文章时有意没有参考现有的 Python 之禅中文译本。因此，这里是我们自行翻译选定的译本，可能在理解上有不到位的地方，也可能文字润色不够精要，大家也可以参考其他的译本形成你的理解和润色版本。

1. 美观胜于丑陋 （ Beautiful is better than ugly. ）
2. 明确胜于隐晦 （ Explicit is better than implicit. ）
3. 简单胜过复杂 （ Simple is better than complex. ）
4. 复杂胜过错综复杂 （ Complex is better than complicated. ）
5. 扁平胜过嵌套 （ Flat is better than nested. ）
6. 稀疏胜过密集 （ Sparse is better than dense. ）
7. 可读性很重要 （ Readability counts. ）
8. 特殊情况不足以违反规则 （ Special cases aren't special enough to break the rules. ）
9. 虽然，实用性胜过纯洁性 （ Although practicality beats purity. ）
10. 错误绝不应该悄悄传递 （ Errors should never pass silently. ）
11. 除非显式消除 （ Unless explicitly silenced. ）
12. 面对歧义 （ In the face of ambiguity, ） 要拒绝猜测的诱惑 （ refuse the temptation to guess. ）
13. 尽量找一种 （ There should be one - ） 最好是唯一一种明显的解决方案 （ and preferably only one - obvious way to do it. ）
14. 虽然这种方式一开始可能并不明显 （ Although that way may not be obvious at first. ） （除非你是荷兰人） （ unless you're Dutch. ）
15. 现在有总比永远没有好 （ Now is better than never. ）
16. 虽然将来总比现在好 （ Although never is often better than right now. ）
17. 如果一个实现难以解释 （ If the implementation is hard to explain, ） 那就是个坏思路 （ it's a bad idea. ）
18. 如果一个实现易于解释 （ If the implementation is easy to explain, ） 那它可能是一个好思路 （ it may be a good idea. ）
19. 命名空间是一个非常棒的想法 （ Namespaces are one honking great idea— ） 让我们做更多的命名空间！ （ let's do more of those! ）