Python 创始人 Guido van Rossum 前段时间宣布脱离 Python 决策层，辞去所谓的 BDFL (终生仁慈的独裁者) 身份曾引发热议，当时他以 PEP 572 改进提案的争吵事件为例，表明其退出缘由。近日 Guido van Rossum 在接受外媒 InfoWorld 采访时，再次聊到了关于他退出决策层背后的隐情，以及对 Python 开发流程的看法。
InfoWorld：为什么辞去 BDFL 职务？
van Rossum：其实，所谓的终生和独裁都只是玩笑话。在过去十年的大部分时间里，我一直有退休的念头。我自身有一些健康问题，雪上加霜的是我需要无数次地去告诉社区的人们该如何做事并保持冷静，也需要无数次地去向别人解释 Python 的语言哲学。
压倒骆驼的最后一根稻草是一个非常有争议的 Python 改进提案（即 PEP 572 ），在我接受它之后，他们去了像 Twitter 这样的社交媒体并说出了一些真正伤害我个人的话语。而且说这些事情的实际上都是 Python 的核心开发者，所以我觉得我们相互之间已不再信任。
InfoWorld：能否谈谈 PEP 572 提案的好处以及为何如此具有争议性？
van Rossum：该提案是关于给 Python 添加表达式内赋值的一种语法。总而言之，这是给语言的一个很小的补充，主要是让人们在需要时，将赋值放在表达式的中间。其实许多其他语言也有类似的次要功能，包括我熟悉的 C 和 C ++。Java 和 JavaScript 据我所知也有支持 。它是一种相当小的语法，但在某些情况下，可以使代码更容易编写，并且通过删除冗余也更容易阅读。
很多人认为他们知道 Python 的设计理念是什么，而这个提议他们觉得没有遵循 Python 的设计原则。 该提案引起争议的另一个原因是提案作者有点自我，前面的几个版本存在一些严重的问题，导致之后即使是同意其基本理念的人，也投了反对票。 这是一个轻微的语法变化，并不激进。
InfoWorld：该特性将包含在哪个版本的 Python 中？
van Rossum：Python 3.8 。
InfoWorld：会有另一个 BDFL 吗？ Python 后续将如何管理？
van Rossum：很遗憾，我目前无法告诉你。我给了核心开发团队一个任务，就是思考后续的管理模式以及选出相关负责人。这应该会是一个长期的讨论，无法立即达成共识。
现在可以说的是，他们已经同意给出提案的截止日期是2018年10月1日。我相信，到2018年11月1日，他们会选出一个合理的管理提案。到2019年1月1日，他们承诺会完成选举或任命负责人。
如果有提案认为需要一个 BDFL ，那么该提案必须详细列明细节，比如说要如何选择 BDFL ，任命期是多久，以及他/她在哪种情况下能被弹劾。不排除到1月1日，他们真能选出这样一个人。
InfoWorld：您将在 Python 项目中担任什么角色？
van Rossum：我将成为常规贡献者或常规核心开发者的角色，偶尔写一些和审查一些代码。我将尝试专注于指导核心开发者，尤其是新的核心开发者，以及女性和少数群体，因为核心开发团队的多样性是我的目标之一。
InfoWorld：您是否担心作为 BDFL ，您的离开可能会吓跑一些 Python 爱好者？
van Rossum：我不这么认为。 Python 拥有一个非常健康的社区，核心团队也拥有非常强大的能力。如果我认为他们无法克服这一点困难并在未来几十年内继续引领语言发展，我就不会辞职。我认为这只是一次轻微的打击，尽管出现了，但我期待后续版本的成功以及开发流程的逐步演变。
InfoWorld：Python 过去几年的开发流程是怎样的？如何看待其未来发展？
van Rossum：语言在不断变化，我们为该语言和库添加了一些新特性。过去几年变化较大的可能是语言的流行度，直到五年前，Python 还一直感觉自己是一个“小玩家”。
之后随着数据科学的发展，Python 作为其主要工具出现了令人难以置信的快速发展。这也导致核心开发者在决策上有更大的压力，但是一般情况下，我们发布语言的方式非常稳定。
我们有发行管理员（release managers），主要版本发行间隔约一年半，Bug 修复版本，由于使用需要，可能会在几个月到大半年左右。
我们也有非常稳定的 Python 改进提案流程。也许随着社交媒体的发展 PEP 的方式有所改变，但总的来说，除了几年前从 Mercurial 转向 Git 之外，PEP 一直是一个非常稳定的流程，没有出现过失误和问题。
文末知识点摘要：Python类中的方法是如何工作的
在OO(面向对象)编程中，类中的方法有多种形式：实例方法、静态方法、类方法、甚至还可以有抽象方法，本文来说说实例方法在Python中是如何工作的，后面再来谈其他方法。
先来定义一个最简单类：
class Person:
def __init__(self, name):
self.name = name
def eat(self):
print(self) # <__main__.person object="" at="">
print(type(self)) #
print(self.name + " is eating")
这里的 eat 就是一个实例方法，跟普通函数差不多，唯一的不同是必须指定一个参数 self，尽管名字可以任意命名，但约定俗成的叫 self，self 是什么？它代表Person类的实例对象，就像Java中的this一样，看下面的测试代码
p = Person("zhangsan")
p.eat()
p与self指向同一个实例对象
那么可不可以通过类直接调用呢？不行！
Person.eat()
TypeError: eat() missing 1 required positional argument: 'self'
那为什么通过实例p调用eat方法不需要传递self参数呢？这个就要从函数与方法的区别说起。来看看下面的代码：
print(Person.eat)
print(p.eat)
# 输出
>
前者是函数，后者是方法，有人说函数定义在类外面，方法定义在类里面，显示这种说法不全面，那么他们的区别在哪里？
首先方法是与某个对象相关联的，而函数则不是，p.eat 就是一个绑定了实例对象的方法，函数的所有参数都需要显示地传递，而方法中的数据是隐式传递的。Person.eat是函数，参数要显示地传递，Person.eat(p)
而方法因为绑定了实例对象，所以他调用的时候无需再传递实例对象了，直接调用p.eat()就可以了，self参数Python会自动传递过去，如果重复传递会报错。
p.eat(p)
TypeError: eat() takes 1 positional argument but 2 were given
所以，本质上
p.eat() 等价于 Person.eat(p)
那么对于实例方法，self 参数从语言设计的角度来说，是不是可以去掉呢，这个问题 Python 之父 Guido van Rossum 撰文解释过这件事，理由是 “Explicit is better than implicit”
本篇文章分享到此结束，部分素材来源网络，如有侵权，请联系删除，希望本次分享对正在学习Python的你有所帮助。
閱讀更多 菜鳥學Python 的文章
