2020年一开年，我们就遇到了一个天大的“黑天鹅”事件，如今它已蔓延成为了一个全球性事件，而且似乎还要持续一段挺长的时间。各行各业的人们都受到了牵连，各种计划和安排也要被迫作出调整。今年的 PyCon US 原计划于 4 月 15 日在匹茨堡（一座美国城市）举行，受到疫情影响，无奈取消！然而，官方很快又发布了新消息，宣布会通过线上方式，来分享录制好的演讲、教程和海报等内容！官方给出了以下的订阅通道：邮件订阅：https://us.pycon.org/2020/online/YouTube订阅：https://www.youtube.com/channel/UCMjMBMGt0WJQLeluw6qNJuATwitter关注：https://twitter.com/pycon在两天前，最新的一封邮件披露了线上分享内容的细节：除了常规的资料型内容，还会有虚拟展厅；从 4 月 15 日开始，线上分享会持续一个月！这应该是前所未有的先例，虽然不是在线直播，但对 Python 开发者/爱好者们来说，已是极大的好消息了！我迫不及待地订阅/关注了！也许还有读者不是很了解 PyCon，我给大家稍微科普一下：所谓 PyCon，就是在 PSF （Python 软件基金会）授意下，各个国家或地区的开发者们自行组织的一种活动。一般而言，活动每年办一次，持续两三天时间，主体内容是嘉宾们的主题演讲，同时还有闪电 ...继续阅读 (49)

在编程语言中有两个很基础的概念，即方法（method）和函数（function）。如果达到了编程初级/入门级水平，那么你肯定在心中已有了初步的答案。也许在你心中已有答案了除去入参、返回值、匿名函数之类的正确的形式内容之外，你也许会说“函数就是定义在类外面的，而方法就是定义在类里面的，跟类绑定的”。这种说法有没有问题呢？当然有！不然我就不会专门写这篇文章了，本文主要会来厘清这个问题。在标准库inspect中，它提供了两个自省的函数，即 ismethod() 和 isfunction()，可以用来判断什么是方法，什么是函数。因此，本文想要先来研究一下这两个函数，看看 Python 在处理方法/函数的概念时，是怎么做的？关于它们的用法，先看一个最简单的例子：运行的结果分别是“True”和“False”，表明我们所定义的 test() 是一个函数，而不是一个方法。这两个函数也可以用来检测自身，不难验证出它们都是一种函数：那么，接下来的问题是：inspect 库的两个函数是什么工作原理呢？先来看看 inspect 中的实现代码：在源码中，我们看到了 isinstance() 函数，它主要用于判断一个对象（object）是否是某个类（class）的实例（instance）。我们还看到了types.FunctionType及types.MethodType，它们指的就是目标类。继续点进去看源码： ...继续阅读 (52)

一个月前（2月20日），一则新的 PEP 没有受到任何阻碍就被官方采纳了，这么快的速度，似乎并不多见。然而，更为高效率的是，仅在半个月内，它的实现就被合入了代码仓。也就是说，我们最快有望在 3 天后（3月23日）发布的 3.9.0 alpha 5 版本中看到它！Python 3.9 的发布计划：这个 PEP 就是PEP-614：放宽对装饰器的语法限制。当前装饰器的语法为：decorator:'@'dotted_name['('[arglist]')']NEWLINEPEP-614 提议将其简化为：decorator:'@'namedexpr_test NEWLINE我已经把 PEP 全文翻译出来了，Github 地址：http://dwz.date/RV9放宽对装饰器的限制，这对之前的用法没有影响，但至于会带来哪些新的好处，我还不知道有哪些现实的例子。下面是 PEP 翻译后的核心内容摘录，先跟大家一睹为快吧：--------------摘录分割线----------------概要Python 当前要求所有装饰器都由 dotted name 组成，可选地带一个调用。本 PEP 提议消除这些限制，并允许任何有效的表达式作为装饰器。（译注：dotted name，指的是装饰器在“@”符号后是“xxx”或“xxx.yyy”这种格式。没有很好地译法，故未译。）动机在最初引入装饰器时，Gui ...继续阅读 (61)

有一个这样的问题：现要用 setuptools 把一个项目打包成 whl 文件，然后 pip install 在 Windows/Linux 两种操作系统上，但是该项目中有一些依赖库只有 Windows 上才有（例如 pywinauto、pywingui、pywinrm），那么问题是，如何实现打包文件的可兼容性安装？从打包的角度，这个问题的关键还是看 setup.py 和 requirements.txt 文件。关于 Python 的包构建分发和 setup.py 的使用，这里有篇文章写得很好，推荐阅读。另外关于 Python 依赖库的管理（requirements.txt），这篇文章详细比较了 pip、pipreqs、pigar、pip-tools 和 pipdeptree 等工具，也推荐一读。有一个比较笨的实现方法：维护两份 requirements.txt 文件，分别用来打包，然后分发给不同操作系统去使用。但是这样会有麻烦：维护两份依赖文件和两种包文件，本身就挺费劲的，而在生成过程中，每次还得对它们改名以作区分（注意包名有一定的规范约束，乱改的话，pip 可能识别不出），维护成本就很高。其实，维护软件包在不同操作系统的版本，并不少见。如果你曾留意过不同版本 Python 库文件的话，你会注意到很多库都会按不同操作系统而分发不同的版本。例如，下面是同一版本号的 Numpy 在不 ...继续阅读 (55)

前不久，我写了一篇《Fabric教程》，简单来说，它是一个用 Python 开发的轻量级的远程系统管理工具，在远程登录服务器、执行 Shell 命令、批量管理服务器、远程部署等场景中，十分好用。Fabric 2 是其最新的大版本，跟早前的 Fabric 1 有挺大的不同，更加好用了，但是没填上的坑也挺多的……本文继续来聊聊 Fabric，不过我不想再面面俱到了，而是专注于这一个话题：它是如何实现对批量服务器的串行/并发管理的？（友情提示：为了有更好的阅读体验，如果你还不了解 Fabric 的基础用法，建议先阅读前面的教程。）Fabric 通过 Group 来组合多台服务器。区别在于由 fabric.group.Group 基类（父类）派生出的两个子类：SerialGroup(*hosts, **kwargs)：按串行方式执行操作ThreadingGroup(*hosts, **kwargs)：按并发方式执行操作下面先看看这个基类：我把一些没用的信息折叠了，比较值得注意的内容有：Group 继承了 list，所以能够 extend() ，对传入的服务器分别建立 connection核心的 run() 方法没有写实现，用意是留给子类再实现最后的 __enter__() 和 __exit__() 实现了上下文管理器有了这个基类，接下来就要看 SerialGroup 和 Threading ...继续阅读 (50)

我之前的一篇文章，带大家揭晓了 Python 在给内置对象分配内存时的 5 个奇怪而有趣的小秘密。文中使用了sys.getsizeof()来计算内存，但是用这个方法计算时，可能会出现意料不到的问题。文档中关于这个方法的介绍有两层意思：该方法用于获取一个对象的字节大小（bytes）它只计算直接占用的内存，而不计算对象内所引用对象的内存也就是说，getsizeof() 并不是计算实际对象的字节大小，而是计算“占位对象”的大小。如果你想计算所有属性以及属性的属性的大小，getsizeof() 只会停留在第一层，这对于存在引用的对象，计算时就不准确。例如列表 [1,2]，getsizeof() 不会把列表内两个元素的实际大小算上，而只是计算了对它们的引用。举一个形象的例子，我们把列表想象成一个箱子，把它存储的对象想象成一个个球，现在箱子里有两张纸条，写上了球 1 和球 2 的地址（球不在箱子里），getsizeof() 只是把整个箱子称重（含纸条），而没有根据纸条上地址，找到两个球一起称重。1、计算的是什么？我们先来看看列表对象的情况：如图所示，单独计算 a 和 b 列表的结果是 36 和 48，然后把它们作为 c 列表的子元素时，该列表的计算结果却仅仅才 36。（PS：我用的是 32 位解释器）如果不使用引用方式，而是直接把子列表写进去，例如 “d = [[1,2],[1,2,3,4,5 ...继续阅读 (63)

关于 Python 自动化的话题，在上一篇文章中，我介绍了 Invoke 库，它是 Fabric 的最重要组件之一。Fabric 也是一个被广泛应用的自动化工具库，是不得不提的自动化运维利器，所以，本文将来介绍一下它。Fabric 主要用在应用部署与系统管理等任务的自动化，简单轻量级，提供有丰富的 SSH 扩展接口。在 Fabric 1.x 版本中，它混杂了本地及远程两类功能；但自 Fabric 2.x 版本起，它分离出了独立的 Invoke 库，来处理本地的自动化任务，而 Fabric 则聚焦于远程与网络层面的任务。为了做到这点，Fabric 主要依赖另一大核心组件 Paramiko，它是基于 SSH 协议的远程控制模块，Fabric 在其基础上封装出了更加友好的接口，可以远程执行 Shell 命令、传输文件、批量操作服务器、身份认证、多种配置与设置代理，等等。一、Fabric 的版本区分Python 2 版本已经被官宣在今年元旦“退休”了，未来只会是 Python 3 的舞台。为了适应 Python 版本的非兼容性迁移，很多项目也必须推出自己的新版本（兼容或只支持 Python 3），其中就包括本文的主角 Fabric。Fabric 自身存在着 2 个大版本：Fabric 1 和 Fabric 2，而在这个库的基础上，还有两个很容易混淆的相关库：Fabric2 和 Fabric ...继续阅读 (49)

接着前面的《tox 教程》，以及刚翻译好的《nox文档》，我们继续聊聊 Python 任务自动化的话题。nox 的作者在去年的 Pycon US 上，做了一场题为《Break the Cycle: Three excellent Python tools to automate repetitive tasks》的分享（B站观看地址：https://b23.tv/av86640235），她介绍了三个任务自动化工具：tox、nox和 invoke，本文的话题正好就是最后的 invoke。1、invoke 可以做什么？invoke 是从著名的远程部署工具 Fabric 中分离出来的，它与 paramiko 一起是 Fabric 的两大最核心的基础组件。除了作为命令行工具，它专注于“任务执行”（task execution），可以标注和组织任务，并通过 CLI（command-line interface，即命令行界面） 和 shell 命令来执行任务。同样是任务自动化工具，invoke 与我们之前介绍过的 tox/nox 在侧重点上有所不同：tox/nox 主要是在打包、测试、持续集成等方面的自动化（当然它们能做的还不止于此）invoke 则更具普遍性，可以用在任何需要“执行任务”的场景，可以是无相关性的任务组，也可以是有顺序依赖的分步骤的工作流invoke 在 Github 上有 2 ...继续阅读 (50)

英文|Python Tips and Trick, You Haven’t Already Seen原作| Martin Heinz (https://martinheinz.dev)译者| 豌豆花下猫声明：本文获得原作者授权翻译，转载请保留原文出处，请勿用于商业或非法用途。有许许多多文章写了 Python 中的许多很酷的特性，例如变量解包、偏函数、枚举可迭代对象，但是关于 Python 还有很多要讨论的话题，因此在本文中，我将尝试展示一些我知道的和在使用的，但很少在其它文章提到过的特性。那就开始吧。1、对输入的字符串“消毒”对用户输入的内容“消毒”，这问题几乎适用于你编写的所有程序。通常将字符转换为小写或大写就足够了，有时你还可以使用正则表达式来完成工作，但是对于复杂的情况，还有更好的方法：user_input="This\nstring has\tsome whitespaces...\r\n"character_map={ord('\n'):' ',ord('\t'):' ',ord('\r'):None}user_input.translate(character_map)# This string has some whitespaces... "在此示例中，你可以看到空格字符“ \n”和“ \t”被单个空格替换了，而“ \r”则被完全删除。这是一个简单的示例，但是我们可 ...继续阅读 (47)

英文|I’m not feeling the async pressure【1】原作| Armin Ronacher，2020.01.01译者| 豌豆花下猫@Python猫声明：本翻译基于CC BY-NC-SA 4.0【2】授权协议，内容略有改动，转载请保留原文出处，请勿用于商业或非法用途。异步（async）正风靡一时。异步Python、异步Rust、go、node、.NET，任选一个你最爱的语言生态，它都在使用着一些异步。异步这东西有多好，这在很大程度上取决于语言的生态及其运行时间，但总体而言，它有一些不错的好处。它使得这种事情变得非常简单：等待可能需要一些时间才能完成的操作。它是如此简单，以至于创造了无数新的方法来坑人（blow ones foot off）。我想讨论的一种情况是，直到系统出现超载，你才意识到自己踩到了脚的那一种，这就是背压（back pressure）管理的主题。在协议设计中有一个相关术语是流量控制（flow control）。什么是背压关于背压的解释有很多，我推荐阅读的一个很好的解释是：Backpressure explained — the resisted flow of data through software【3】。因此，与其详细介绍什么是背压，我只想对其做一个非常简短的定义和解释：背压是阻碍数据在系统中流通的阻力。背压听起来很负面——谁都会想象浴 ...继续阅读 (61)

原作：Archie Mistry翻译：豌豆花下猫@Python猫原文：https://morioh.com/p/765b19f066a4Python 是一门对初学者友好的编程语言，是一种多用途的、解释性的和面向对象的高级语言。它拥有非常小的程序集，非常易于学习、阅读和维护。其解释器可在Windows、Linux 和 Mac OS 等多种操作系统上使用。它的可移植性和可伸缩性等特性使得它更加容易被运用。Python 库可用于以下用途：Web 开发数据科学机器学习多媒体软件开发像 Django 这样的 Web 框架GUI 应用大多数极客认为 Python 是解释性语言，但它也存在编译过程。编译部分在代码执行时完成，并被删除。然后编译内容被转换为字节码。通过机器和操作系统进一步扩展到 Python 虚拟机。本文重点介绍了适用于 Python 程序员的 11 种最佳的 Python 编译器和解释器。最好的 Python 编译器和解释器1.BrythonBrython 是一种流行的 Python 编译器，可将 Python 转换为 Javascript 代码。它提供对所有 Web 浏览器（包括一种手机 Web 浏览器）的支持。它还支持最新的 Html5/CSS3 规范，可以使用流行的 CSS 框架，如 BootStrap3 和 LESS。网址：https://brython.info2. P ...继续阅读 (55)

在最新一期的“Python开发者周刊”（Pycoder’s weekly）里，我看到一则有意思的分享，故转出来分享给大家。该分享来自是一份”python weekly reports“，统计了 2019 年里 stackoverflow 网站上支持数最高的 20 个问题。问题列表如下（方括号中的两个数字是其支持数与回答数）：Why does Python’s hash of infinity have the digits of π?- [236/3]Is there a more elegant way to express ((x == a and y == b) or (x == b and y == a))?- [105/10]Why can I use a list index as an indexing variable in a for loop?- [92/6]Why does (inf + 0j)*1 evaluate to inf + nanj?- [93/4]Why is f’{{{74}}}’ the same as f’{{74}}’ with f-Strings?- [88/1]Why does b+=(4,) work and b = b + (4,) doesn’t work when b is a list?- [75/7]Why does P ...继续阅读 (58)

在我刚翻译完的 Python 打包系列文章中，作者提到了一个神奇的测试工具 tox，而且他本人就是 tox 的维护者之一。趁着话题的相关性，本文将对它做简单的介绍，说不定大家在开发项目时能够用得上。Command line driven CI frontend and development task automation tool命令行驱动的 CI 前端和开发任务自动化工具tox 的项目地址是：https://github.com/tox-dev/tox其核心作用是支持创建隔离的 Python 环境，在里面可以安装不同版本的 Python 解释器与各种依赖库，以此方便开发者做自动化测试、打包、持续集成等事情。简单来说，tox 是一个管理测试虚拟环境的命令行工具。它已存在多年且广被开发者们使用，例如，著名的云计算平台 OpenStack 也采用了它，作为最基础的测试工具之一。1、tox 能做什么？细分的用途包括：创建开发环境运行静态代码分析与测试工具自动化构建包针对 tox 构建的软件包运行测试检查软件包是否能在不同的 Python 版本/解释器中顺利安装统一持续集成（CI）和基于命令行的测试创建和部署项目文档将软件包发布到 PyPI 或任何其它平台tox 官方文档中列出了 40 余种使用场景的示例，详细的列表可查看：https://tox.readthedocs.io/en/la ...继续阅读 (55)

花下猫语：这是 packaging 系列的第三篇译文，该系列是全网关于此话题的最详尽（水平也很高）的一个系列。原作者是 Python 官方打包团队成员，是 virtualenv 和 tox 项目的维护者，及 setuptools 和 pip 项目的贡献者。英文|Python packaging - Growing Pains【1】原作| BERNAT GABOR译者| 豌豆花下猫声明：本文获得原作者授权翻译，转载请保留原文出处，请勿用于商业或非法用途。在前两篇文章中，我介绍了Python 具有的包类型以及包的构建方式，尤其介绍了 PEP-517/518。尽管这些更改主要是为了使打包变得更健壮，但是在实施和发布时，我们却遇到了一些问题。这篇文章将介绍一部分，希望可以为大家提供经验教训，并提出一些有趣的问题以待将来解决。查看 PEP-517 和 PEP-518 的改动，可以认为构建后端（亦即 setuptools、flit）几乎没有做什么，只是通过 Python 模块提供了功能接口。大部分繁重的工作都在构建前端上，它需要生成隔离的 Python，然后以新的方式调用构建后端。如今当我们谈论构建前端时，我们的选项主要是 pip 或 poetry（和开发者的 tox）。这些项目由社区维护，由少数活跃的开发者在空闲时间维护。他们并没有因此获得报酬，而且需要谨慎考虑这些工具被使用的多种方式。考虑 ...继续阅读 (58)

英文|Python packaging - Past, Present, Future【1】原作| BERNAT GABOR译者| 豌豆花下猫声明：本文获得原作者授权翻译，转载请保留原文出处，请勿用于商业或非法用途。你是否想过在运行 pip install 时究竟发生了什么？这篇文章将给你一个关于过去所涉及的步骤的详细综述，以及它是如何随着 PEP-517 和 PEP-518 的采用而改变的。在前一篇文章中，我描述了如何做到安装三种类型的内容：源码树（source tree）、源发行版（source distribution）和 wheel。只有最后两种类型会被上传到 PyPi 中央存储仓，但你也可以获得源码树（例如，通过为 pip 加入 git 协议）。与其它类型相比，wheel 的优点是不需要在用户机器上进行任何构建操作；只需要下载和提取。构建 Python 包现在可以独立出构建的环境（用户或开发者的机器），但你仍然需要构建包（sdist 或 wheel）。为了做到这一点，你需要一些适当的构建器。在过去，对第三方包的需求很早就表现出来了。遵循内置电池的原则，在 2000 年的 Python 1.6 中，distutils【2】包被添加进 Python 标准库中。它引入了包含构建逻辑的setup.py文件的概念，并通过python setup.py命令触发。它允许用户将代码打包成 ...继续阅读 (62)

英文|The state of Python Packaging【1】原作| BERNAT GABOR译者| 豌豆花下猫声明：本文获得原作者授权翻译，转载请保留原文出处，请勿用于商业或非法用途。pip19.0 已经于 2019 年 1 月 22 日发布。在其功能列表中，最值得注意的是它现在支持 PEP-517，默认情况下是支持的，如果项目的根目录中有一个 pyproject.toml。该 PEP 于 2015 年创建，并于 2017 年被接受。尽管 pip 花了一段时间才实现它，但该版本及其后续问题却表明，很多人根本不熟悉它。如果你想了解 Python 打包（packaging）生态的现状及将来如何演变，请继续阅读。我们希望，即使上述提到的 Python 增强提案（译注：即 PEP，关于 PEP 的介绍，请阅读这篇文章），如今可能会引起一些不愉快，但从长远来看，我们将从中受益。我大约在三年前加入了 Python 开源社区（尽管使用它已有 8 年之久）。从早期开始，我就听说 Python 打包有一点黑匣子的名声。它有很多未知的内容，人们通常只复制其它项目的构建配置文件，就使用上了。在尝试更好地理解这个黑匣子，并对其进行改进的过程中，我已经成为了 virtualenv 和 tox 项目的维护者，偶尔也为 setuptools 和 pip 做些贡献。我希望对这个主题进行详尽的（并希望是一 ...继续阅读 (69)

2020 年 1 月 1 日是 Python2 的寿命终止日，这个日期在两年前经”Python之父” Guido van Rossum 宣布，此后一直成为开发者社区翘首以盼的一天。昨天就是这个大快人心的日子，各种变了花样的喜庆报道不绝于目。调侃的玩笑也不少，比如这个：还有这个（别信！）：然而，我今天偶然看到一位大佬的疑问，大意如下：官网发布的 Python2 退休日期说是 4 月，那个倒计时网站是不是冒充的官方消息？他所说的官网消息是这篇——怎么回事呢？传了那么久的元旦退休消息，竟然会不准确？那么多人在热热闹闹地庆祝着，竟然是在庆祝一个假消息么？我搜索那篇文章，仔细读了一遍，然后才注意到发布日期是 2019 年 12 月 20 日，也就是两周前。文中没有提到 1 月 1 日，也没提 4 月的具体日子。文章属实，但日期明显矛盾，这是怎么回事呢？官方应该会有所解释吧？带着疑问，我去翻看官方和几个核心开发者的推特。经过一番资料查阅，我终于搞清楚了怎么回事，也找到了所谓的”官方解释”。简单说明结论：2020-01-01 是板上钉钉的 Python2 的 EOL (end of life，寿命终止)日子，但是在这个日子前的版本发布周期还在进行，最后一个版本按计划是在今年 4 月的 Pycon US 大会上发布。Python2.7 在 2019 年的最后一个版本是 10 月 19 日发布的 2 ...继续阅读 (54)

现在是 2020 年的第一天，我相信从昨天开始，各位的信息流里肯定充斥了各式各样的年度盘点/回顾/总结/记录之类的内容。虽然来得稍晚了，但我还是想给诸位送上这一篇文章。我将在本文中列出自己于 2019 年度里最喜爱的 10 篇 Python 文章。我的选择标准是极为个性化的，甚至会有点任性，因为我的第一条标准是：文章必须是我原创或者翻译的。如标题所言，这就是“我的”文章榜单。同时，为了丰富本文内容，我在榜单之后，还会附上其他人所盘点的文章榜单，给大家呈上更多的精彩内容。我的年度十佳文章Python 中 -m 的典型用法、原理解析与发展演变Python 内存分配时的小秘密Python进阶：全面解读高级特性之切片！len(x) 击败 x.len()，从内置函数看 Python 的设计思想编程语言之问：何时该借用，何时该创造？Python 之父撰文回忆：为什么要创造 pgen 解析器？Python 进阶之源码分析：如何将一个类方法变为多个方法？遇见一只黑猫，她说Python是个怪物[译] PEP 318—函数和方法的装饰器聊聊 Python 的内置电池/聊聊 print 的前世今生附录三份榜单：1、爱湃森年度 Python 榜单Our journey to type checking 4 million lines of PythonTutorial: Advanced Jupyter ...继续阅读 (100)

前一篇文章《Python 中如何实现参数化测试？》中，我提到了在 Python 中实现参数化测试的几个库，并留下一个问题：它们是如何做到把一个方法变成多个方法，并且将每个方法与相应的参数绑定起来的呢？我们再提炼一下，原问题等于是：在一个类中，如何使用装饰器把一个类方法变成多个类方法（或者产生类似的效果）？# 带有一个方法的测试类classTestClass:deftest_func(self):pass# 使用装饰器，生成多个类方法classTestClass:deftest_func1(self):passdeftest_func2(self):passdeftest_func3(self):passPython 中装饰器的本质就是移花接木，用一个新的方法来替代被装饰的方法。在实现参数化的过程中，我们介绍过的几个库到底用了什么手段/秘密武器呢？1、ddt 如何实现参数化？先回顾一下上篇文章中 ddt 库的写法：importunittestfromddtimportddt,data,unpack@ddtclassMyTest(unittest.TestCase):@data((3,1),(-1,0),(1.2,1.0))@unpackdeftest(self,first,second):passddt 可提供 4 个装饰器：1 个加在类上的 @ddt，还有 3 个加在类方法上的 @ ...继续阅读 (56)

之前，我曾转过一个单元测试框架系列的文章，里面介绍了 unittest、nose/nose2 与 pytest 这三个最受人欢迎的 Python 测试框架。本文想针对测试中一种很常见的测试场景，即参数化测试，继续聊聊关于测试的话题，并尝试将这几个测试框架串联起来，做一个横向的比对，加深理解。1、什么是参数化测试？对于普通测试来说，一个测试方法只需要运行一遍，而参数化测试对于一个测试方法，可能需要传入一系列参数，然后进行多次测试。比如，我们要测试某个系统的登录功能，就可能要分别传入不同的用户名与密码，进行测试：使用包含非法字符的用户名、使用未注册的用户名、使用超长的用户名、使用错误的密码、使用合理的数据等等。参数化测试是一种“数据驱动测试”（Data-Driven Test），在同一个方法上测试不同的参数，以覆盖所有可能的预期分支的结果。它的测试数据可以与测试行为分离，被放入文件、数据库或者外部介质中，再由测试程序读取。2、参数化测试的实现思路？通常而言，一个测试方法就是一个最小的测试单元，其功能应该尽量地原子化和单一化。先来看看两种实现参数化测试的思路：一种是写一个测试方法，在其内部对所有测试参数进行遍历；另一种是在测试方法之外写遍历参数的逻辑，然后依次调用该测试方法。这两种思路都能达到测试目的，在简单业务中，没有毛病。然而，实际上它们都只有一个测试单元，在统计测试用例数情况，或者 ...继续阅读 (59)

在命令行中使用 Python 时，它可以接收大约 20 个选项（option），语法格式如下：python[-bBdEhiIOqsSuvVWx?][-c command|-m module-name|script|-][args]本文想要聊聊比较特殊的“-m”选项：关于它的典型用法、原理解析与发展演变的过程。首先，让我们用“—help”来看看它的解释：-m mod run library module as a script (terminates option list)“mod”是“module”的缩写，即“-m”选项后面的内容是 module（模块），其作用是把模块当成脚本来运行。“terminates option list”意味着“-m”之后的其它选项不起作用，在这点上它跟“-c”是一样的，都是“终极选项”。官方把它们定义为“接口选项”（Interface options），需要区别于其它的普通选项或通用选项。-m 选项的五个典型用法Python 中有很多使用 -m 选项的场景，相信大家可能会用到或者看见过，我在这里想分享 5 个。在 Python3 中，只需一行命令就能实现一个简单的 HTTP 服务：python-m http.server8000# 注:在 Python2 中是这样python-m SimpleHTTPServer8000执行后，在本机打开“http ...继续阅读 (59)

在 Python 的项目中，如何管理所用的全部依赖库呢？最主流的做法是维护一份“requirements.txt”，记录下依赖库的名字及其版本号。那么，如何来生成这份文件呢？在上篇文章《由浅入深：Python 中如何实现自动导入缺失的库？》中，我提到了一种常规的方法：pip freeze>requirements.txt这种方法用起来方便，但有几点不足：它搜索依赖库的范围是全局环境，因此会把项目之外的库加入进来，造成冗余（一般是在虚拟环境中使用，但还是可能包含无关的依赖库）它只会记录以“pip install”方式安装的库它对依赖库之间的依赖关系不做区分它无法判断版本差异及循环依赖等情况…………可用于项目依赖管理的工具有很多，本文主要围绕与 requirements.txt 文件相关的、比较相似却又各具特色的 4 个三方库，简要介绍它们的使用方法，罗列一些显著的功能点。至于哪个是最好的管理方案呢？卖个关子，请往下看……pipreqs这是个很受欢迎的用于管理项目中依赖库的工具，可以用“pip install pipreqs”命令来安装。它的主要特点有：搜索依赖库的范围是基于目录的方式，很有针对性搜索的依据是脚本中所 import 的内容可以在未安装依赖库的环境上生成依赖文件查找软件包信息时，可以指定查询方式（只在本地查询、在 PyPi 查询、或者在自定义的 PyPi 服务）基本的命令 ...继续阅读 (59)

在写 Python 项目的时候，我们可能经常会遇到导入模块失败的错误：ImportError: No module named 'xxx'或者ModuleNotFoundError: No module named 'xxx'。导入失败问题，通常分为两种：一种是导入自己写的模块（即以 .py 为后缀的文件），另一种是导入三方库。本文主要讨论第二种情况，今后有机会，我们再详细讨论其它的相关话题。解决导入 Python 库失败的问题，其实关键是在运行环境中装上缺失的库（注意是否是虚拟环境），或者使用恰当的替代方案。这个问题又分为三种情况：一、单个模块中缺失的库在编写代码的时候，如果我们需要使用某个三方库（如 requests），但不确定实际运行的环境是否装了它，那么可以这样写：try:importrequestsexceptImportError:importos os.system('pip install requests')importrequests这样写的效果是，如果找不到 requests 库，就先安装，再导入。在某些开源项目中，我们可能还会看到如下的写法（以 json 为例）：try:importsimplejsonasjsonexceptImportError:importjson这样写的效果是，优先导入三方库 simplejson，如果找不到，那就使用内置的标 ...继续阅读 (58)

导语：Python 3.8 已经发布了，引进了不少变更点。关于 3.9 预计引入的修改，也披露了一些。我们之前还关注过GIL 的移除计划和Guido 正在开发的新解析器等话题，这意味 Python 很有活力，仍在健康地发展着。Python 3 是比较大胆激进的，抛弃了前一版本的很多陈旧的包袱，但同时，它也是相对克制的（一直如此），社区里提出的很多提议都被否决了。前不久，我分享的Python 设计和历史的 27 个问题提到了一些沉淀下来的设计问题，今天这篇译文则聚焦于官方明确否决掉的 24 个设计问题。大部分问题都是细枝末节（例如大小写、括号、反引号、行宽等等），但细究起来的话，也会挺有意思，欢迎留言讨论。PEP原文：https://www.python.org/dev/peps/pep-0399PEP标题：Things that will Not Change in Python 3000PEP作者：Georg Brandl创建日期：2006-04-04译者：豌豆花下猫（Python猫公众号作者）翻译计划：https://github.com/chinesehuazhou/peps-cn目录概要语言核心内置对象标准类型编码风格交互式解释器版权概要有些想法很糟糕。尽管关于 Python 演化的某些想法具有建设性，但不少想法却与 Python 的基本原则背道而驰，就像是让人围着圈跑步： ...继续阅读 (53)

人生之中的某些时候，我会拥有对异化之物的感受：理念的含义不再附着于实际之物，认为某物应该是什么功用，但是在现实生活中，它是别的功用，或者就没有用。我不记得是何时学得一个词叫作“硬币”，但几乎肯定是在课本或者影视作品里，也就是说，不在日常生活里。在我家乡那边，也有硬币，但是我们的方言称它为“银子”（并不是古代的银子），不叫“硬币”。方言里也没有“纸币”或者“钞票”的叫法，而是直接把它们称为“钱”，所以在很长一段时间里，我所知道的“钱”就是那一张张的壹角、贰角、伍角或壹元之类的纸币，纸币与“钱”划上了充分的等号。这两个名称的差异延迟了我加入一个更大的语境，后来才知道“银子”和“钱”一样都是钱。也就是说，直到获取了生活之外的知识，我才知道“银子”也属于钱，并不是只有纸“钱”才是钱。一般而言，人们是在生活中首次接触，并理解那些理论上的名称概念，而不在书本或类似的知识库。关于“硬币”这个概念，我的情况恰好相反。它成为了一种“异化之物”。在我家乡那边，“银子”并不在日常买卖行为中流通（至今仍如此），“店子”（即杂货铺、乡间便利店）和其它商贩不接受“银子”。所以，我小时候缺少把它认知为一种钱的环境。为什么硬币不作为货币而流通使用？原因我不得而知，只能认为这是当地的习俗。习俗是这样的：很多人家都收藏有一袋“银子”，不分年代，不分新旧，以壹分和壹角的居多，不用于交易，但用途却不少。我曾在衣橱的衣服堆 ...继续阅读 (63)

国庆假期里，我跟豌豆从苏州去江西丰城参加了一场婚礼。新娘 Y 是豌豆的闺蜜、大学室友，她们自开学第一天起相识，至今已有 11 年。本科毕业后，她去了上海，而豌豆读研毕业后来了苏州，两地不远，我们常有联络。她们共同的大学闺蜜 C 同学携了男友，也从江苏连云港前去赴约。饭桌席间，Y 同学的哥哥对 C 同学说起当年的一件往事，感慨地说，“你们毕业都已经 7 年了，7 年过得好快啊！”大家问知我们都是从江苏而来，又都语带感慨的说“江苏好远啊”。两座城市相距有 700 多公里，向来缺乏距离感的我，对此发不起感慨，然而说到这几年的时间，像是睡了一觉醒来时朦胧而把握不住地消失了，我就自己严肃了起来。得益于那些年的文字涂鸦，我有一笔财富可以去巡视，每次读到自己写的带有时间标记的、带有年岁模样的文字，我就又感触到时间的力量，知道记忆和文字的力量。所以，“7 年时间过去了”这个话题（除了“毕业”之外，“7 年”还有别的含义），被我反复强化它的重要性，现在促使自己苦坐，要以这种方式把某些东西留下来。这会是写给未来的我们看的，当某一天我们需要一种支撑，需要一个慰藉，需要一份安定，需要一份快乐的时候，也许它可以释放出这些东西来。一场完整的中国小镇婚礼或许可以找出一个比较早的起点，比如订婚、领证、计算良辰吉日、布置婚房，或者是新娘在吉日的凌晨 4 点多起床梳妆打扮。这些时间和事件是一场婚礼的序曲。我听她们说起 ...继续阅读 (56)

前两天，我偶然在一个知识星球（刘欣老师的“码农翻身”）里看到一篇主题，刘老师表示 Python 的类方法非要带个 self，而不像其它语言那样隐藏起来，这让人很不爽。我对此也有同感。在经过群聊讨论后，我获知 Guido 曾经专门撰文解释过这个问题。这篇文章并不好懂，我抽空先翻译出来了，看看能收到什么回应。如果可能的话，后续再另写文章分析。--------------以下为译文---------------布鲁斯·埃克尔（Bruce Eckel）发了篇博文，提议从类方法的形参列表中删除“self”。我将解释为什么这个提议不能通过。（译注：Bruce 是《Thinking in Java》、《Thinking in C++》等多本书籍的作者，也是个 Python 开发者。他的文章总结了当年在巴西 Pycon 上的一次讨论，主要观点是在定义类方法时，形参中的“self”是多余的，而且由它引发的报错信息具有一定的误导性。）Bruce 的提议Bruce 知道，我们需要一种方法来区分对实例变量的引用和对其它变量的引用，因此他建议将“self”设为关键字。考虑一种典型的类，它有一个方法，例如：classC:defmeth(self,arg):self.val=argreturnself.val跟据 Bruce 的提议，这将变为：classC:defmeth(arg):# Look ma, no ...继续阅读 (55)

原题|A Meta-Grammar for PEG Parsers作者| Guido van Rossum（Python之父）译者| 豌豆花下猫（“Python猫”公众号作者）声明| 本翻译是出于交流学习的目的，基于CC BY-NC-SA 4.0授权协议。为便于阅读，内容略有改动。本系列的译文已在 Github 开源，项目地址：https://github.com/chinesehuazhou/guido_blog_translation本周我们使解析器生成器完成“自托管”（self-hosted），也就是让它自己生成解析器。首先我们有了一个解析器生成器，其中一部分是语法解析器。我们可以称之为元解析器（meta-parser）。该元解析器与要生成的解析器类似：GrammarParser继承自Parser，它使用相同的 mark()/reset()/expect() 机制。然而，它是手写的。但是，只能是手写么？在编译器设计中有一个传统，即编译器使用它要编译的语言编写。我深切地记得在我初学编程时，当时用的 Pascal 编译器是用 Pascal 本身编写的，GCC 是用 C 编写的，Rust 编译器当然是用 Rust 编写的。这是怎么做到的呢？有一个辅助过程（bootstrap，引导程序，通常译作“自举”）：对于一种语言的子集或早期版本，它的编译器是用其它的语言编写的。（我记得最初的 ...继续阅读 (57)

本周的PyCoder's Weekly上分享了一篇小文章，它里面提到的冷知识很有意思，我稍作补充，分享给大家。它提到的部分问题，读者们可以先思考下：若两个元组相等，即 a==b 且 a is b，那么相同索引的元素（如 a[0] 、b[0]）是否必然相等呢？若两个对象的 hash 结果相等，即 hash(a) == hash(b)，那么它们是否必然相等呢？答案当然都为否（不然就不叫冷知识了），大家可以先尝试回答一下，然后再往下看。-----思考分割线-----好了，先来看看第一个问题。两个相同的元组 a、b，它们有如下的关系：>>>a=(float('nan'),)>>>b=a>>>a# (nan,)>>>b# (nan,)>>>type(a),type(b)(,)>>>a==bTrue>>>aisb# 即 id(a) == id(b)True>>>a[0]==b[0]False以上代码表明：a 等于 b（类型、值与 id 都相等），但是它们的对位元素却不相等。两个元组都只有一个元素（逗号后面没有别的元素，这是单元素的元组的表示方法，即 len(a)==1 ）。float() 是个内置函数，可以将入参构造成一个浮点数。为什么会这样呢？先查阅一下文档，这个内置函数的解析规则是：sign::="+"|"-"infinity::="Infinity"|"inf"nan::="nan"nu ...继续阅读 (58)

大家或许知道，Python 为了提高内存的利用效率，采用了一套共用对象内存的分配策略。例如，对于那些数值较小的数字对象（[-5, 256]）、布尔值对象、None 对象、较短的字符串对象（通常是 20）等等，字面量相等的对象实际上是同一个对象。# 共用内存地址的例子a=100b=100s="python_cat"t="python_cat"id(a)==id(b)# 结果：Trueid(s)==id(t)# 结果：True我很早的时候曾写过一篇《Python中的“特权种族”是什么？》，把这些对象统称为“特权种族”，它们是 Python 在内存管理机制上使用的优化技巧。前不久，我还写了一篇《Python 内存分配时的小秘密》，也是介绍内存管理的技巧。这两篇文章有所区别：旧文主要涉及了内存共用与对象驻留的机制，而新文介绍的是内存分配、动态扩容以及内存回收的相关机制。它们令我不由自主地想到两个词：共享经济与供需平衡。如果你没有读过那两篇文章，我强烈建议你先回看一下，然后再看看我的联想是否有道理：那几类特权种族对象其实是在共享内存，表面上的不同对象，其实是在循环利用；至于供需平衡也好理解，创建某些对象时，按照预期的诉求去分配内存，在扩容时则灵活调节，达到了供需之间的平衡。透过现象看本质，Python 可以很有趣。但是，Python 的有趣之处还不止于此，本文要继续分享另一种内存管理机制，在 ...继续阅读 (57)