
正文
python函数前向引用 python 函数引用另一个函数变量
提示:扫一扫查出行【扫一扫了解最新限行尾号】
复制提示
如何用 Python 实现一个图数据库(Graph Database)?
本文章是 重写 500 Lines or Less 系列的其中一篇,目标是重写 500 Lines or Less 系列的原有项目:Dagoba: an in-memory graph database。
Dagoba 是作者设计用来展示如何从零开始自己实现一个图数据库( Graph Database )。该名字似乎来源于作者喜欢的一个乐队,另一个原因是它的前缀 DAG 也正好是有向无环图 ( Directed Acyclic Graph ) 的缩写。本文也沿用了该名称。
图是一种常见的数据结构,它将信息描述为若干独立的节点( vertex ,为了和下文的边更加对称,本文中称为 node ),以及把节点关联起来的边( edge )。我们熟悉的链表以及多种树结构可以看作是符合特定规则的图。图在路径选择、推荐算法以及神经网络等方面都是重要的核心数据结构。
既然图的用途如此广泛,一个重要的问题就是如何存储它。如果在传统的关系数据库中存储图,很自然的做法就是为节点和边各自创建一张表,并用外键把它们关联起来。这样的话,要查找某人所有的子女,就可以写下类似下面的查询:
还好,不算太复杂。但是如果要查找孙辈呢?那恐怕就要使用子查询或者 CTE(Common Table Expression) 等特殊构造了。再往下想,曾孙辈又该怎么查询?孙媳妇呢?
这样我们会意识到,SQL 作为查询语言,它只是对二维数据表这种结构而设计的,用它去查询图的话非常笨拙,很快会变得极其复杂,也难以扩展。针对图而言,我们希望有一种更为自然和直观的查询语法,类似这样:
为了高效地存储和查询图这种数据结构,图数据库( Graph Database )应运而生。因为和传统的关系型数据库存在极大的差异,所以它属于新型数据库也就是 NoSql 的一个分支(其他分支包括文档数据库、列数据库等)。图数据库的主要代表包括 Neo4J 等。本文介绍的 Dagoba 则是具备图数据库核心功能、主要用于教学和演示的一个简单的图数据库。
原文代码是使用 JavaScript 编写的,在定义调用接口时大量使用了原型( prototype )这种特有的语言构造。对于其他主流语言的用户来说,原型的用法多少显得有些别扭和不自然。
考虑到本系列其他数据库示例大多是用 Python 实现的,本文也按照传统,用 Python 重写了原文的代码。同样延续之前的惯例,为了让读者更好地理解程序是如何逐步完善的,我们用迭代式的方法完成程序的各个组成部分。
原文在 500lines 系列的 Github 仓库中只包含了实现代码,并未包含测试。按照代码注释说明,测试程序位于作者的另一个代码库中,不过和 500lines 版本的实现似乎略有不同。
本文实现的代码参考了原作者的测试内容,但跳过了北欧神话这个例子——我承认确实不熟悉这些神祇之间的亲缘关系,相信中文背景的读者们多数也未必了解,虽然作者很喜欢这个例子,想了想还是不要徒增困惑吧。因此本文在编写测试用例时只参考了原文关于家族亲属的例子,放弃了神话相关的部分,尽管会减少一些趣味性,相信对于入门级的代码来说这样也够用了。
本文实现程序位于代码库的 dagoba 目录下。按照本系列程序的同意规则,要想直接执行各个已完成的步骤,读者可以在根目录下的 main.py 找到相应的代码位置,取消注释并运行即可。
本程序的所有步骤只需要 Python3 ,测试则使用内置的 unittest , 不需要额外的第三方库。原则上 Python3.6 以上版本应该都可运行,但我只在 Python3.8.3 环境下完整测试过。
本文实现的程序从最简单的案例开始,通过每个步骤逐步扩展,最终形成一个完整的程序。这些步骤包括:
接下来依次介绍各个步骤。
回想一下,图数据库就是一些点( node )和边( edge )的集合。现在我们要做出的一个重大决策是如何对节点/边进行建模。对于边来说,必须指定它的关联关系,也就是从哪个节点指向哪个节点。大多数情况下边是有方向的——父子关系不指明方向可是要乱套的!
考虑到扩展性及通用性问题,我们可以把数据保存为字典( dict ),这样可以方便地添加用户需要的任何数据。某些数据是为数据库内部管理而保留的,为了明确区分,可以这样约定:以下划线开头的特殊字段由数据库内部维护,类似于私有成员,用户不应该自己去修改它们。这也是 Python 社区普遍遵循的约定。
此外,节点和边存在互相引用的关系。目前我们知道边会引用到两端的节点,后面还会看到,为了提高效率,节点也会引用到边。如果仅仅在内存中维护它们的关系,那么使用指针访问是很直观的,但数据库必须考虑到序列化到磁盘的问题,这时指针就不再好用了。
为此,最好按照数据库的一般要求,为每个节点维护一个主键( _id ),用主键来描述它们之间的关联关系。
我们第一步要把数据库的模型建立起来。为了测试目的,我们使用一个最简单的数据库模型,它只包含两个节点和一条边,如下所示:
按照 TDD 的原则,首先编写测试:
与原文一样,我们把数据库管理接口命名为 Dagoba 。目前,能够想到的最简单的测试是确认节点和边是否已经添加到数据库中:
assert_item 是一个辅助方法,用于检查字典是否包含预期的字段。相信大家都能想到该如何实现,这里就不再列出了,读者可参考 Github 上的完整源码。
现在,测试是失败的。用最简单的办法实现数据库:
需要注意的是,不管添加节点还是查询,程序都使用了拷贝后的数据副本,而不是直接使用原始数据。为什么要这样做?因为字典是可变的,用户可以在任何时候修改其中的内容,如果数据库不知道数据已经变化,就很容易发生难以追踪的一致性问题,最糟糕的情况下会使得数据内容彻底混乱。
拷贝数据可以避免上述问题,代价则是需要占用更多内存和处理时间。对于数据库来说,通常查询次数要远远多于修改,所以这个代价是可以接受的。
现在测试应该正常通过了。为了让它更加完善,我们可以再测试一些边缘情况,看看数据库能否正确处理异常数据,比如:
例如,如果用户尝试添加重复主键,我们预期应抛出 ValueError 异常。因此编写测试如下:
为了满足以上测试,代码需要稍作修改。特别是按照 id 查找主键是个常用操作,通过遍历的方法效率太低了,最好是能够通过主键直接访问。因此在数据库中再增加一个字典:
完整代码请参考 Github 仓库。
在上个步骤,我们在初始化数据库时为节点明确指定了主键。按照数据库设计的一般原则,主键最好是不具有业务含义的代理主键( Surrogate key ),用户不应该关心它具体的值是什么,因此让数据库去管理主键通常是更为合理的。当然,在部分场景下——比如导入外部数据——明确指定主键仍然是有用的。
为了同时支持这些要求,我们这样约定:字段 _id 表示节点的主键,如果用户指定了该字段,则使用用户设置的值(当然,用户有责任保证它们不会重复);否则,由数据库自动为它分配一个主键。
如果主键是数据库生成的,事先无法预知它的值是什么,而边( edge )必须指定它所指向的节点,因此必须在主键生成后才能添加。由于这个原因,在动态生成主键的情况下,数据库的初始化会略微复杂一些。还是先写一个测试:
为支持此功能,我们在数据库中添加一个内部字段 _next_id 用于生成主键,并让 add_node 方法返回新生成的主键:
接下来,再确认一下边是否可以正常访问:
运行测试,一切正常。这个步骤很轻松地完成了,不过两个测试( DbModelTest 和 PrimaryKeyTest )出现了一些重复代码,比如 get_item 。我们可以把这些公用代码提取出来。由于 get_item 内部调用了 TestCase.assertXXX 等方法,看起来应该使用继承,但从 TestCase 派生基类容易引起一些潜在的问题,所以我转而使用另一个技巧 Mixin :
实现数据库模型之后,接下来就要考虑如何查询它了。
在设计查询时要考虑几个问题。对于图的访问来说,几乎总是由某个节点(或符合条件的某一类节点)开始,从与它相邻的边跳转到其他节点,依次类推。所以链式调用对查询来说是一种很自然的风格。举例来说,要知道 Tom 的孙子养了几只猫,可以使用类似这样的查询:
可以想象,以上每个方法都应该返回符合条件的节点集合。这种实现是很直观的,不过存在一个潜在的问题:很多时候用户只需要一小部分结果,如果它总是不计代价地给我们一个巨大的集合,会造成极大的浪费。比如以下查询:
为了避免不必要的浪费,我们需要另外一种机制,也就是通常所称的“懒式查询”或“延迟查询”。它的基本思想是,当我们调用查询方法时,它只是把查询条件记录下来,而并不立即返回结果,直到明确调用某些方法时才真正去查询数据库。
如果读者比较熟悉流行的 Python ORM,比如 SqlAlchemy 或者 Django ORM 的话,会知道它们几乎都是懒式查询的,要调用 list(result) 或者 result[0:10] 这样的方法才能得到具体的查询结果。
在 Dagoba 中把触发查询的方法定义为 run 。也就是说,以下查询执行到 run 时才真正去查找数据:
和懒式查询( Lazy Query )相对应的,直接返回结果的方法一般称作主动查询( Eager Query )。主动查询和懒式查询的内在查找逻辑基本上是相同的,区别只在于触发机制不同。由于主动查询实现起来更加简单,出错也更容易排查,因此我们先从主动查询开始实现。
还是从测试开始。前面测试所用的简单数据库数据太少,难以满足查询要求,所以这一步先来创建一个更复杂的数据模型:
此关系的复杂之处之一在于反向关联:如果 A 是 B 的哥哥,那么 B 就是 A 的弟弟/妹妹,为了查询到他们彼此之间的关系,正向关联和反向关联都需要存在,因此在初始化数据库时需要定义的边数量会很多。
当然,父子之间也存在反向关联的问题,为了让问题稍微简化一些,我们目前只需要向下(子孙辈)查找,可以稍微减少一些关联数量。
因此,我们定义数据模型如下。为了减少重复工作,我们通过 _backward 字段定义反向关联,而数据库内部为了查询方便,需要把它维护成两条边:
然后,测试一个最简单的查询,比如查找某人的所有孙辈:
这里 outcome/income 分别表示从某个节点出发、或到达它的节点集合。在原作者的代码中把上述方法称为 out/in 。当然这样看起来更加简洁,可惜的是 in 在 Python 中是个关键字,无法作为函数名。我也考虑过加个下划线比如 out_.in_ 这种形式,但看起来也有点怪异,权衡之后还是使用了稍微啰嗦一点的名称。
现在我们可以开始定义查询接口了。在前面已经说过,我们计划分别实现两种查询,包括主动查询( Eager Query )以及延迟查询( Lazy Query )。
它们的内在查询逻辑是相通的,看起来似乎可以使用继承。不过遵循 YAGNI 原则,目前先不这样做,而是只定义两个新类,在满足测试的基础上不断扩展。以后我们会看到,与继承相比,把共同的逻辑放到数据库本身其实是更为合理的。
接下来实现访问节点的方法。由于 EagerQuery 调用查询方法会立即返回结果,我们把结果记录在 _result 内部字段中。虽然 node 方法只返回单个结果,但考虑到其他查询方法几乎都是返回集合,为统一起见,让它也返回集合,这样可以避免同时支持集合与单结果的分支处理,让代码更加简洁、不容易出错。此外,如果查询对象不存在的话,我们只返回空集合,并不视为一个错误。
查询输入/输出节点的方法实现类似这样:
查找节点的核心逻辑在数据库本身定义:
以上使用了内部定义的一些辅助查询方法。用类似的逻辑再定义 income ,它们的实现都很简单,读者可以直接参考源码,此处不再赘述。
在此步骤的最后,我们再实现一个优化。当多次调用查询方法后,结果可能会返回重复的数据,很多时候这是不必要的。就像关系数据库通常支持 unique/distinct 一样,我们也希望 Dagoba 能够过滤重复的数据。
假设我们要查询某人所有孩子的祖父,显然不管有多少孩子,他们的祖父应该是同一个人。因此编写测试如下:
现在来实现 unique 。我们只要按照主键把重复数据去掉即可:
在上个步骤,初始化数据库指定了双向关联,但并未测试它们。因为我们还没有编写代码去支持它们,现在增加一个测试,它应该是失败的:
运行测试,的确失败了。我们看看要如何支持它。回想一下,当从边查找节点时,使用的是以下方法:
这里也有一个潜在的问题:调用 self.edges 意味着遍历所有边,当数据库内容较多时,这是巨大的浪费。为了提高性能,我们可以把与节点相关的边记录在节点本身,这样要查找边只要看节点本身即可。在初始化时定义出入边的集合:
在添加边时,我们要同时把它们对应的关系同时更新到节点,此外还要维护反向关联。这涉及对字典内容的部分复制,先编写一个辅助方法:
然后,将添加边的实现修改如下:
这里的代码同时添加正向关联和反向关联。有的朋友可能会注意到代码略有重复,是的,但是重复仅出现在该函数内部,本着“三则重构”的原则,暂时不去提取代码。
实现之后,前面的测试就可以正常通过了。
在这个步骤中,我们来实现延迟查询( Lazy Query )。
延迟查询的要求是,当调用查询方法时并不立即执行,而是推迟到调用特定方法,比如 run 时才执行整个查询,返回结果。
延迟查询的实现要比主动查询复杂一些。为了实现延迟查询,查询方法的实现不能直接返回结果,而是记录要执行的动作以及传入的参数,到调用 run 时再依次执行前面记录下来的内容。
如果你去看作者的实现,会发现他是用一个数据结构记录执行操作和参数,此外还有一部分逻辑用来分派对每种结构要执行的动作。这样当然是可行的,但数据处理和分派部分的实现会比较复杂,也容易出错。
本文的实现则选择了另外一种不同的方法:使用 Python 的内部函数机制,把一连串查询变换成一组函数,每个函数取上个函数的执行结果作为输入,最后一个函数的输出就是整个查询的结果。由于内部函数同时也是闭包,尽管每个查询的参数形式各不相同,但是它们都可以被闭包“捕获”而成为内部变量,所以这些内部函数可以采用统一的形式,无需再针对每种查询设计额外的数据结构,因而执行过程得到了很大程度的简化。
首先还是来编写测试。 LazyQueryTest 和 EagerQueryTest 测试用例几乎是完全相同的(是的,两种查询只在于内部实现机制不同,它们的调用接口几乎是完全一致的)。
因此我们可以把 EagerQueryTest 的测试原样不变拷贝到 LazyQueryTest 中。当然拷贝粘贴不是个好注意,对于比较冗长而固定的初始化部分,我们可以把它提取出来作为两个测试共享的公共函数。读者可参考代码中的 step04_lazy_query/tests/test_lazy_query.py 部分。
程序把查询函数的串行执行称为管道( pipeline ),用一个变量来记录它:
然后依次实现各个调用接口。每种接口的实现都是类似的:用内部函数执行真正的查询逻辑,再把这个函数添加到 pipeline 调用链中。比如 node 的实现类似下面:
其他接口的实现也与此类似。最后, run 函数负责执行所有查询,返回最终结果;
完成上述实现后执行测试,确保我们的实现是正确的。
在前面我们说过,延迟查询与主动查询相比,最大的优势是对于许多查询可以按需要访问,不需要每个步骤都返回完整结果,从而提高性能,节约查询时间。比如说,对于下面的查询:
以上查询的意思是从孙辈中找到一个符合条件的节点即可。对该查询而言,主动查询会在调用 outcome('son') 时就遍历所有节点,哪怕最后一步只需要第一个结果。而延迟查询为了提高效率,应在找到符合条件的结果后立即停止。
目前我们尚未实现 take 方法。老规矩,先添加测试:
主动查询的 take 实现比较简单,我们只要从结果中返回前 n 条记录:
延迟查询的实现要复杂一些。为了避免不必要的查找,返回结果不应该是完整的列表( list ),而应该是个按需返回的可迭代对象,我们用内置函数 next 来依次返回前 n 个结果:
写完后运行测试,确保它们是正确的。
从外部接口看,主动查询和延迟查询几乎是完全相同的,所以用单纯的数据测试很难确认后者的效率一定比前者高,用访问时间来测试也并不可靠。为了测试效率,我们引入一个节点访问次数的概念,如果延迟查询效率更高的话,那么它应该比主动查询访问节点的次数更少。
为此,编写如下测试:
我们为 Dagoba 类添加一个成员来记录总的节点访问次数,以及两个辅助方法,分别用于获取和重置访问次数:
然后浏览代码,查找修改点。增加计数主要在从边查找节点的时候,因此修改部分如下:
此外还有 income/outcome 方法,修改都很简单,这里就不再列出。
实现后再次运行测试。测试通过,表明延迟查询确实在效率上优于主动查询。
不像关系数据库的结构那样固定,图的形式可以千变万化,查询机制也必须足够灵活。从原理上讲,所有查询无非是从某个节点出发按照特定方向搜索,因此用 node/income/outcome 这三个方法几乎可以组合出任意所需的查询。
但对于复杂查询,写出的代码有时会显得较为琐碎和冗长,对于特定领域来说,往往存在更为简洁的名称,例如:母亲的兄弟可简称为舅舅。对于这些场景,如果能够类似 DSL (领域特定语言)那样允许用户根据专业要求自行扩展,从而简化查询,方便阅读,无疑会更为友好。
如果读者去看原作者的实现,会发现他是用一种特殊语法 addAlias 来定义自己想要的查询,调用方法时再进行查询以确定要执行的内容,其接口和内部实现都是相当复杂的。
而我希望有更简单的方法来实现这一点。所幸 Python 是一种高度动态的语言,允许在运行时向类中增加新的成员,因此做到这一点可能比预想的还要简单。
为了验证这一点,编写测试如下:
无需 Dagoba 的实现做任何改动,测试就可以通过了!其实我们要做的就是动态添加一个自定义的成员函数,按照 Python 对象机制的要求,成员函数的第一个成员应该是名为 self 的参数,但这里已经是在 UnitTest 的内部,为了和测试类本身的 self 相区分,新函数的参数增加了一个下划线。
此外,函数应返回其所属的对象,这是为了链式调用所要求的。我们看到,动态语言的灵活性使得添加新语法变得非常简单。
到此,一个初具规模的图数据库就形成了。
和原文相比,本文还缺少一些内容,比如如何将数据库序列化到磁盘。不过相信读者都看到了,我们的数据库内部结构基本上是简单的原生数据结构(列表+字典),因此序列化无论用 pickle 或是 JSON 之类方法都应该是相当简单的。有兴趣的读者可以自行完成它们。
我们的图数据库实现为了提高查询性能,在节点内部存储了边的指针(或者说引用)。这样做的好处是,无论数据库有多大,从一个节点到相邻节点的访问是常数时间,因此数据访问的效率非常高。
但一个潜在的问题是,如果数据库规模非常大,已经无法整个放在内存中,或者出于安全性等原因要实现分布式访问的话,那么指针就无法使用了,必须要考虑其他机制来解决这个问题。分布式数据库无论采用何种数据模型都是一个棘手的问题,在本文中我们没有涉及。有兴趣的读者也可以考虑 500lines 系列中关于分布式和集群算法的其他一些文章。
本文的实现和系列中其他数据库类似,采用 Python 作为实现语言,而原作者使用的是 JavaScript ,这应该和作者的背景有关。我相信对于大多数开发者来说, Python 的对象机制比 JavaScript 基于原型的语法应该是更容易阅读和理解的。
当然,原作者的版本比本文版本在实现上其实是更为完善的,灵活性也更好。如果想要更为优雅的实现,我们可以考虑使用 Python 元编程,那样会更接近于作者的实现,但也会让程序的复杂性大为增加。如果读者有兴趣,不妨对照着去读读原作者的版本。
相关问答
Q1: Python 里为什么函数可以返回一个函数内部定义的函数
“在Python中,函数本身也是对象”
这一本质。那不妨慢慢来,从最基本python函数前向引用的概念开始,讨论一下这个问题python函数前向引用:
1. Python中一切皆对象
这恐怕是学习Python最有用的一句话。想必你已经知道Python中的list, tuple, dict等内置数据结构,当你执行:
alist = [1, 2, 3]
时,你就创建了一个列表对象,并且用alist这个变量引用它:
当然你也可以自己定义一个类:
class House(object):
def __init__(self, area, city):
self.area = area
self.city = city
def sell(self, price):
[...] #other code
return price
然后创建一个类的对象:
house = House(200, 'Shanghai')
OK,你立马就在上海有了一套200平米的房子,它有一些属性(area, city),和一些方法(__init__, self):
2. 函数是第一类对象
和list, tuple, dict以及用House创建的对象一样,当你定义一个函数时,函数也是对象:
def func(a, b):
return a+b
在全局域,函数对象被函数名引用着,它接收两个参数a和b,计算这两个参数的和作为返回值。
所谓第一类对象,意思是可以用标识符给对象命名,并且对象可以被当作数据处理,例如赋值、作为参数传递给函数,或者作为返回值return 等
因此,你完全可以用其他变量名引用这个函数对象:
add = func
这样,你就可以像调用func(1, 2)一样,通过新的引用调用函数了:
print func(1, 2)
print add(1, 2) #the same as func(1, 2)
或者将函数对象作为参数,传递给另一个函数:
def caller_func(f):
return f(1, 2)
if __name__ == "__main__":
print caller_func(func)
可以看到,
函数对象func作为参数传递给caller_func函数,传参过程类似于一个赋值操作f=funcpython函数前向引用;
于是func函数对象,被caller_func函数作用域中的局部变量f引用,f实际指向了函数func;cc
当执行return f(1, 2)的时候,相当于执行了return func(1, 2);
因此输出结果为3。
3. 函数对象 vs 函数调用
无论是把函数赋值给新的标识符,还是作为参数传递给新的函数,针对的都是函数对象本身,而不是函数的调用。
用一个更加简单,但从外观上看,更容易产生混淆的例子来说明这个问题。例如定义了下面这个函数:
def func():
return "hello,world"
然后分别执行两次赋值:
ref1 = func #将函数对象赋值给ref1
ref2 = func() #调用函数,将函数的返回值("hello,world"字符串)赋值给ref2
很多初学者会混淆这两种赋值,通过Python内建的type函数,可以查看一下这两次赋值的结果:
In [4]: type(ref1)
Out[4]: function
In [5]: type(ref2)
Out[5]: str
可以看到,ref1引用了函数对象本身,而ref2则引用了函数的返回值。通过内建的callable函数,可以进一步验证ref1是可调用的,而ref2是不可调用的:
In [9]: callable(ref1)
Out[9]: True
In [10]: callable(ref2)
Out[10]: False
传参的效果与之类似。
4. 闭包LEGB法则
所谓闭包,就是将组成函数的语句和这些语句的执行环境打包在一起时,得到的对象
听上去的确有些复杂,还是用一个栗子来帮助理解一下。假设我们在foo.py模块中做了如下定义:
#foo.py
filename = "foo.py"
def call_func(f):
return f() #如前面介绍的,f引用一个函数对象,然后调用它
在另一个func.py模块中,写下了这样的代码:
#func.py
import foo #导入foo.py
filename = "func.py"
def show_filename():
return "filename: %s" % filename
if __name__ == "__main__":
print foo.call_func(show_filename) #注意:实际发生调用的位置,是在foo.call_func函数中
当我们用python func.py命令执行func.py时输出结果为:
chiyu@chiyu-PC:~$ python func.py
filename:func.py
很显然show_filename()函数使用的filename变量的值,是在与它相同环境(func.py模块)中定义的那个。尽管foo.py模块中也定义了同名的filename变量,而且实际调用show_filename的位置也是在foo.py的call_func内部。
而对于嵌套函数,这一机制则会表现的更加明显:闭包将会捕捉内层函数执行所需的整个环境:
#enclosed.py
import foo
def wrapper():
filename = "enclosed.py"
def show_filename():
return "filename: %s" % filename
print foo.call_func(show_filename) #输出:filename: enclosed.py
实际上,每一个函数对象,都有一个指向了该函数定义时所在全局名称空间的__globals__属性:
#show_filename inside wrapper
#show_filename.__globals__
{
'__builtins__': module '__builtin__' (built-in), #内建作用域环境
'__file__': 'enclosed.py',
'wrapper': function wrapper at 0x7f84768b6578, #直接外围环境
'__package__': None,
'__name__': '__main__',
'foo': module 'foo' from '/home/chiyu/foo.pyc', #全局环境
'__doc__': None
}
当代码执行到show_filename中的return "filename: %s" % filename语句时,解析器按照下面的顺序查找filename变量:
Local - 本地函数(show_filename)内部,通过任何方式赋值的,而且没有被global关键字声明为全局变量的filename变量;
Enclosing - 直接外围空间(上层函数wrapper)的本地作用域,查找filename变量(如果有多层嵌套,则由内而外逐层查找,直至最外层的函数);
Global - 全局空间(模块enclosed.py),在模块顶层赋值的filename变量;
Builtin - 内置模块(__builtin__)中预定义的变量名中查找filename变量;
在任何一层先找到了符合要求的filename变量,则不再向更外层查找。如果直到Builtin层仍然没有找到符合要求的变量,则抛出NameError异常。这就是变量名解析的:LEGB法则。
总结:
闭包最重要的使用价值在于:封存函数执行的上下文环境;
闭包在其捕捉的执行环境(def语句块所在上下文)中,也遵循LEGB规则逐层查找,直至找到符合要求的变量,或者抛出异常。
5. 装饰器语法糖(syntax sugar)
那么闭包和装饰器又有什么关系呢python函数前向引用?
上文提到闭包的重要特性:封存上下文,这一特性可以巧妙的被用于现有函数的包装,从而为现有函数更加功能。而这就是装饰器。
还是举个例子,代码如下:
#alist = [1, 2, 3, ..., 100] -- 1+2+3+...+100 = 5050
def lazy_sum():
return reduce(lambda x, y: x+y, alist)
我们定义了一个函数lazy_sum,作用是对alist中的所有元素求和后返回。alist假设为1到100的整数列表:
alist = range(1, 101)
但是出于某种原因,我并不想马上返回计算结果,而是在之后的某个地方,通过显示的调用输出结果。于是我用一个wrapper函数对其进行包装:
def wrapper():
alist = range(1, 101)
def lazy_sum():
return reduce(lambda x, y: x+y, alist)
return lazy_sum
lazy_sum = wrapper() #wrapper() 返回的是lazy_sum函数对象
if __name__ == "__main__":
lazy_sum() #5050
这是一个典型的Lazy Evaluation的例子。我们知道,一般情况下,局部变量在函数返回时,就会被垃圾回收器回收,而不能再被使用。但是这里的alist却没有,它随着lazy_sum函数对象的返回被一并返回了(这个说法不准确,实际是包含在了lazy_sum的执行环境中,通过__globals__),从而延长了生命周期。
当在if语句块中调用lazy_sum()的时候,解析器会从上下文中(这里是Enclosing层的wrapper函数的局部作用域中)找到alist列表,计算结果,返回5050。
当你需要动态的给已定义的函数增加功能时,比如:参数检查,类似的原理就变得很有用:
def add(a, b):
return a+b
这是很简单的一个函数:计算a+b的和返回,但我们知道Python是 动态类型+强类型 的语言,你并不能保证用户传入的参数a和b一定是两个整型,他有可能传入了一个整型和一个字符串类型的值:
In [2]: add(1, 2)
Out[2]: 3
In [3]: add(1.2, 3.45)
Out[3]: 4.65
In [4]: add(5, 'hello')
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
/home/chiyu/ipython-input-4-f2f9e8aa5eae in module()
---- 1 add(5, 'hello')
/home/chiyu/ipython-input-1-02b3d3d6caec in add(a, b)
1 def add(a, b):
---- 2 return a+b
TypeError: unsupported operand type(s) for +: 'int' and 'str'
于是,解析器无情的抛出了一个TypeError异常。
动态类型:在运行期间确定变量的类型,python确定一个变量的类型是在你第一次给他赋值的时候;
强类型:有强制的类型定义,你有一个整数,除非显示的类型转换,否则绝不能将它当作一个字符串(例如直接尝试将一个整型和一个字符串做+运算);
因此,为了更加优雅的使用add函数,我们需要在执行+运算前,对a和b进行参数检查。这时候装饰器就显得非常有用:
import logging
logging.basicConfig(level = logging.INFO)
def add(a, b):
return a + b
def checkParams(fn):
def wrapper(a, b):
if isinstance(a, (int, float)) and isinstance(b, (int, float)): #检查参数a和b是否都为整型或浮点型
return fn(a, b) #是则调用fn(a, b)返回计算结果
#否则通过logging记录错误信息,并友好退出
logging.warning("variable 'a' and 'b' cannot be added")
return
return wrapper #fn引用add,被封存在闭包的执行环境中返回
if __name__ == "__main__":
#将add函数对象传入,fn指向add
#等号左侧的add,指向checkParams的返回值wrapper
add = checkParams(add)
add(3, 'hello') #经过类型检查,不会计算结果,而是记录日志并退出
注意checkParams函数:
首先看参数fn,当我们调用checkParams(add)的时候,它将成为函数对象add的一个本地(Local)引用;
在checkParams内部,我们定义了一个wrapper函数,添加了参数类型检查的功能,然后调用了fn(a, b),根据LEGB法则,解释器将搜索几个作用域,并最终在(Enclosing层)checkParams函数的本地作用域中找到fn;
注意最后的return wrapper,这将创建一个闭包,fn变量(add函数对象的一个引用)将会封存在闭包的执行环境中,不会随着checkParams的返回而被回收;
当调用add = checkParams(add)时,add指向了新的wrapper对象,它添加了参数检查和记录日志的功能,同时又能够通过封存的fn,继续调用原始的add进行+运算。
因此调用add(3, 'hello')将不会返回计算结果,而是打印出日志:
chiyu@chiyu-PC:~$ python func.py
WARNING:root:variable 'a' and 'b' cannot be added
有人觉得add = checkParams(add)这样的写法未免太过麻烦,于是python提供了一种更优雅的写法,被称为语法糖:
@checkParams
def add(a, b):
return a + b
这只是一种写法上的优化,解释器仍然会将它转化为add = checkParams(add)来执行。
6. 回归问题
def addspam(fn):
def new(*args):
print "spam,spam,spam"
return fn(*args)
return new
@addspam
def useful(a,b):
print a**2+b**2
首先看第二段代码:
@addspam装饰器,相当于执行了useful = addspam(useful)。在这里题主有一个理解误区:传递给addspam的参数,是useful这个函数对象本身,而不是它的一个调用结果;
再回到addspam函数体:
return new 返回一个闭包,fn被封存在闭包的执行环境中,不会随着addspam函数的返回被回收;
而fn此时是useful的一个引用,当执行return fn(*args)时,实际相当于执行了return useful(*args);
最后附上一张代码执行过程中的引用关系图,希望能帮助你理解:
Q2: python 中 @ 是什么意思
修饰符,比如说
class A:
@staticmethod
def m(self):
pass
就相当于
class A:
def m(self):
pass
m = staticmethod(m)
其实就是一调用一个函数参数为下行的变量,并且替换它
扩展资料:
函数修饰符
@用做函数的修饰符,可以在模块或者类的定义层内对函数进行修饰,出现在函数定义的前一行,不允许和函数定义在同一行。
一个修饰符就是一个函数,它将被修饰的函数作为参数,并返回修饰后的同名函数或其他可调用的东西。
在Python的函数中偶尔会看到函数定义的上一行有@functionName的修饰,当解释器读到@这样的修饰符的时候会优先解除@后的内容,直接就把@的下一行的函数或者类作为@后边函数的参数,然后将返回值赋给下一个修饰的函数对象。
参考资料来源:百度百科-Python (计算机程序设计语言)
Q3: Linux 下Python 脚本编写的quot;奇技淫巧quot;
「 生命完美python函数前向引用的答案,无非走过没有遗憾 ---《天蓝》」
「如何能够解析脚本运行命令行选项(位于 sys.argv 中)」
argparse 模块可被用来解析命令行选项
常用来定义一个脚本的说明文档,一般python函数前向引用我们写python脚本会通过 if..else 的方式来提供一个脚本说明文档,python不支持switch。所以很麻烦,其实,我们可以通过 argparse 来编写说明文档。
我们来看看怎么执行一个python脚本
对于熟悉Linux的小伙伴下面的文档在熟悉不过python函数前向引用了,这个一个标准Linxu软件包的说明文档,文档中定义是软件包的说明
来看看这个脚本是如何编写的
为了解析命令行选项, 首先要创建一个 ArgumentParser 实例, 使用 add_argument() 方法声明python函数前向引用你想要支持的选项。在每个 add-argument() 调用中:
dest 参数指定解析结果被指派给属性的名字。 metavar 参数被用来生成帮助信息。
action 参数 指定跟属性对应的处理逻辑,通常的 值为 store , 被用来存储 某个值 或将 多个参数值收集到一个列表中 。
nargs 参数收集 所有剩余的命令行参数到一个列表中。在本例中它被用来构造一个文件名列表
action='store_true' 根据参数是否存在来设置一个位置 Boolean 标志:
action='store' 参数接受一个单独值并将其存储为一个字符串
如果一个都没有,会提示缺少参数 -p/--pat
choices={'slow', 'fast'}, 参数说明接受一个值,但是会将其和可能的选择值做比较,以检测其合法性:
一旦参数选项被指定,你就可以执行 parser.parse() 方法了。它会处理 sys.argv 的值并返回一个结果实例。每个参数值会被设置成该实例中 add_argument() 方法的 dest 参数指定的属性值。
还很多种其他方法解析命令行选项。可以会手动地处理 sys.argv 或者使用 getopt 模块 。但是,如果你采用本节的方式,将会减少很多冗余代码,底层细节 argparse 模块 已经帮你处理好了。你可能还会碰到使用 optparse 库解析选项的代码。尽管 optparse 和 argparse 很像 ,但是后者更先进,因此在新的程序中你应该使用它。
「你写了个脚本,运行时需要一个密码。此脚本是交互式的,因此不能将密码在脚本中硬编码,而是需要弹出一个密码输入提示,让用户自己输入。」
Python 的 getpass 模块 正是你所需要的。你可以让你很轻松地弹出密码输入提示,并且不会在用户终端显示密码。
代码中 getpass.getuser() 不会弹出用户名的输入提示。它会根据该 用户的 shell 环境 或者会依据 本地系统的密码库 (支持 pwd 模块的平台)来使用 当前用户的登录名
在bash中编写pytohn脚本接收外部数据的方式,一般情况下,对于一般变量,我们用命令行变量的方式比较多(手动的处理 sys.argv ),对于 文件内容或者bash命令输出 直接通过脚本内部获取需要的数据。
其实python 脚本也可以用其他方式来接收 传递给他的 文件数据或者bash命令输出 ,包括将 命令行的输出 通过 管道传递 给该脚本、 重定向文件到该脚本 ,或在 命令行中传递一个文件名 或 文件名列表 给该脚本。
这里通过 Python 内置的 fileinput 模块 ,可以实现重 定向,管道,以文佳输出 的方式传递数据到脚本内部
使用 fileinput.input() 方法可以获取当前输入脚本的数据,脚本里面用一个 FileInput 迭代器接收
文件直接接收
重定向接收
管道方式接收
fileinput.input() 创建并返回一个 FileInput 类的实例,该实例可以被当做一个 上下文管理器 使用。因此,整合起来,如果我们要写一个打印多个文件输出的脚本,那么我们需要在输出中包含文件名和行号
「你想执行一个外部命令并以 Python 字符串的形式获取执行结果。」
使用 subprocess.check_output() 函数。
执行下试试
如果被执行的命令以非零码返回,就会抛出异常。下面的例子捕获到错误并获取返回码:
默认情况下, check_output() 仅仅返回输入到标准输出的值。如果你需要 同时收集标准输出和错误输出 ,使用 stderr 参数:
如果你需要用一个超时机制来执行命令,使用 timeout 参数:
通常来讲,命令的执行 不需要 使用到 底层 shell 环境(比如 sh、bash) 。一个字符串列表会被传递给一个 低级系统命令 ,比如 os.execve() 。
如果你想让 命令被一个shell 执行 ,传递一个字符串参数,并设置参数 shell=True . 有时候你想要 Python 去执行一个复杂的 shell 命令 的时候这个就很有用了,比如管道流、I/O 重定向和其他特性。例如:
是在 shell 中执行命令会存在一定的安全风险,特别是当参数来自于用户输入时。这时候可以使用 shlex.quote() 函数 来将参数正确的用双引用引起来。
使用 check_output() 函数 是执行 外部命令 并获取其 返回值 的最简单方式。但是,如果你需要对 子进程做更复杂的交互 ,比如给它发送输入,你得采用另外一种方法。这时候可直接使用 subprocess.Popen 类。
关于子进程,简单来看下
也可以进程列表同协程结合的方式。你既可以在子shell中 进行繁重的处理工作,同时也不会让子shell的I/O受制于终端。
如果直接丢到后台会自动在终端输出IO
subprocess 模块对于依赖 TTY 的外部命令不合适用 。例如,你不能使用它来自动化一个用户输入密码的任务(比如一个 ssh 会话)。这时候,你需要使用到第三方模块了,比如基于著名的 expect 家族的工具(pexpect 或类似的)(pexpect可以理解为Linux下的expect的Python封装、通过pexpect可以实现对ssh、ftp、passwd、telnet等命令行进行自动交互,而无需人工干涉来达到自动化的目的。比如我们可以模拟一个FTP登录时所有交互,包括输入主机地址、用户名、密码、上传文件等,待出现异常还可以进行尝试自动处理。)
「你想向标准错误打印一条消息并返回某个非零状态码来终止程序运行」
通过 python 的 raise SystemExit(3) 命令可以主动抛出一个错误,通过 sys.stderr.write 将命令写到标准的输出端
直接将消息作为参数传给 SystemExit() ,那么你可以省略其他步骤
抛出一个 SystemExit 异常,使用错误消息作为参数,它会将消息在 sys.stderr 中打印,然后程序以状态码 1 退出
「你需要知道当前终端的大小以便正确的格式化输出。」
使用 os.get terminal size() 函数 来做到这一点。
「复制或移动文件和目录,但是又不想调用 shell 命令。」
shutil 模块 有很多便捷的函数可以复制文件和目录。使用起来非常简单
这里不多讲,熟悉Linux的小伙伴应该不陌生。
默认情况下,对于 符号链接 这些命令处理的是它指向的东西文件。例如,如果 源文件 是一个 符号链接 ,那么目标文件将会是 符号链接 指向的文件。如果你只想 复制符号链接本身 ,那么需要指定 关键字 参数 follow_symlinks
copytree() 可以让你在复制过程中选择性的忽略某些文件或目录。你可以提供一个忽略函数,接受一个目录名和文件名列表作为输入,返回一个忽略的名称列表。例如:
对于文件元数据信息, copy2() 这样的函数只能尽自己最大能力来保留它。 访问时间、创建时间和权限 这些基本信息会被保留,但是 对于所有者、ACLs、资源 fork 和其他更深层次的文件元信息就说不准了
通常不会去使用 shutil.copytree() 函数 来执行 系统备份 。当处理文件名的时候,最好使用 os.path 中的函数来确保最大的可移植性
使用 copytree() 复制文件夹的一个棘手的问题是对于错误的处理,可以使用异常块处理,或者通过 参数 ignore dangling symlinks=True 忽略掉无效符号链接。
「创建或解压常见格式的归档文件(比如.tar, .tgz 或.zip)」
shutil 模块拥有两个函数—— make archive() 和 unpack archive() 可派上用场,
make archive() 的第二个参数是期望的输出格式。可以使用 get archive formats() 获取所有支持的归档格式列表。
「你需要写一个涉及到文件查找操作的脚本,比如对日志归档文件的重命名工具,你不想在 Python 脚本中调用 shell,或者你要实现一些 shell 不能做的功能。」
查找文件,可使用 os.walk() 函数 ,传一个顶级目录名给它
os.walk() 方法 为我们 遍历目录树 ,每次进入一个目录,它会返回一个 三元组 ,包含 相对于查找目录的相对路径,一个该目录下的目录名列表,以及那个目录下面的文件名列表。
对于每个元组,只需检测一下目标文件名是否在文件列表中。如果是就使用 os.path.join() 合并路径。为了避免奇怪的路径名比如 ././foo//bar ,使用了另外两个函数来修正结果
os.walk(start) 还有跨平台的优势。并且,还能很轻松的加入其他的功能。我们再演示一个例子,下面的函数打印所有最近被修改过的文件:
打印10分钟之前被修改的数据
「怎样读取普通.ini 格式的配置文件?」
configparser 模块 能被用来读取配置文件
编写配置文件
如果有需要,你还能修改配置并使用 cfg.write() 方法将其写回到文件中
「你希望在脚本和程序中将诊断信息写入日志文件。」
python 脚本打印日志最简单方式是使用 logging 模块
五个日志调用( critical(), error(), warning(), info(), debug() )以降序方式表示不同的严重级别。 basicConfig() 的 level 参数是一个 过滤器 。所有级别低于此级别的日志消息都会被忽略掉。每个 logging 操作的参数是一个消息字符串,后面再跟一个或多个参数。构造最终的日志消息的时候我们使用了 % 操作符来格式化消息字符串。
如果你想使用配置文件,可以像下面这样修改 basicConfig() 调用:
logconfig.ini
在调用日志操作前先执行下 basicConfig() 函数方法 ,可以找标准输出或者文件中输出
basicConfig() 在程序中只能被执行一次。如果你稍后想改变日志配置,就需要先获取 root logger ,然后直接修改它。
更多见日志模块文档
「你想给某个函数库增加日志功能,但是又不能影响到那些不使用日志功能的程序。」
对于想要执行日志操作的函数库,你应该创建一个专属的 logger 对象,并且像下面这样初始化配置:
使用这个配置,默认情况下不会打印日志,只有配置过日志系统,那么日志消息打印就开始生效
通常来讲,不应该在函数库代码中 自己配置日志系统 ,或者是已经有个已经存在的日志配置了。调用 getLogger( name ) 创建一个和调用模块同名的 logger 模块 。由于 模块 都是唯一的,因此创建的 logger 也将是唯一 的。所以当前进程中只有一个logging会生效。
log.addHandler(logging.NullHandler()) 操作将一个 空处理器 绑定到刚刚已经创建好的 logger 对象 上。一个空处理器默认会忽略调用所有的日志消息。因此,如果使用该函数库的时候还没有配置日志,那么将不会有消息或警告出现。
在这里,根日志被配置成仅仅 输出 ERROR 或更高级别的消息 。不过, somelib 的日志级别被单独配置成可以输出 debug 级别的消息, 它的优先级比全局配置高。像这样更改单独模块的日志配置对于调试来讲是很方便的,因为你无需去更改任何的全局日志配置——只需要修改你想要更多输出的模块的日志等级。(这个还有待研究)
「你想记录程序执行多个任务所花费的时间」
time 模块 包含很多函数来执行跟时间有关的函数。尽管如此,通常我们会在此基础之上构造一个更高级的接口来模拟一个计时器。
这个类定义了一个可以被用户根据需要启动、停止和重置的计时器。它会在elapsed 属性中记录整个消耗时间。下面是一个例子来演示怎样使用它:
这里通过 __enter__,__exit__ ,使用 with 语句 以及上下文管理器协议可以省略计时器打开和关闭操作。(关于上下文管理协议,即with语句,为了让一个对象兼容with语句,必须在这个对象的类中声明 __enter__和__exit__方法, , __enter__ 在出现with语句被调用, __exit__ 在代码执行完毕被调用,可以参考open()方法)
在计时中要考虑一个 底层的时间函数问题 。 一般来说, 使用 time.time() 或 time.clock() 计算的时间精度因操作系统的不同会有所不同。而使用 time.perf_counter() 函数可以确保使用系统上面 最精确的计时器 。
「你想对在 Unix 系统上面运行的程序设置内存或 CPU 的使用限制。」
resource 模块 能同时执行这两个任务。例如,要限制 CPU 时间,下面的代码在windows平台执行不了,但是Linux是可以的。
程序运行时, SIGXCPU 信号 在时间过期时被生成,然后执行清理并退出。
这暂时没有好的Demo...
程序运行到没有多余内存时会抛出 MemoryError 异常。
setrlimit() 函数 被用来设置特定资源上面的 软限制和硬限制 。
setrlimit() 函数 还能被用来设置 子进程数量、打开文件数以及类似系统资源的限制(cgroup) 。
「通过脚本启动浏览器并打开指定的 URL 网页」
webbrowser 模块 能被用来启动一个浏览器,并且与平台无关
新窗口打卡网站
当前窗口打开一个tab页
指定浏览器类型,可以使用 webbrowser.get() 函数
Q4: 【Python基础】python基本语法规则有哪些?
Python基本语法
Pythonpython函数前向引用的语法相对比C,C++,Java更加简洁,比较符合人python函数前向引用的正常思维。本篇介绍Python的基本语法,通过本篇文章python函数前向引用你可以学到以下内容。
掌握Python的基本语法
识别Python中的关键字
Python是一门脚本语言,有以下特点:
面向对象:类
语法块:使用缩进进行标记
注释: #单行注释,"""多行注释""",'''我也是多行注释''
打印与输出:print(), input()
变量: 变量在赋值的时候确定变量的类型
模块:通过import 模块名进行加载模块
Python的标识符
标识符是用户编程时使用的名字,用于给变量、常量、函数、语句块等命名,以建立起名称与使用之间的关系。标识符通常由字母和数字以及其它字符构成。
标识符的命名遵循以下规定:
开头以字母或者下划线_,剩下的字符数字字母或者下划线
Python遵循小驼峰命名法
不是使用Python中的关键字进行命名
代码示例:
num = 10 # 这是一个int类型变量
错误命名示例:
123rate(数字开头)、 mac book pro(含有空格),class(关键字)
Python关键字
以下列表中的关键字不可以当作标识符进行使用。Python语言的关键字只包含小写字母。
python函数前向引用的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于python 函数引用另一个函数变量、python函数前向引用的信息别忘了在本站进行查找喔。








