你知道疯狂的字典吗?

开发 前端
你可能有个小小的疑问,为什么递归的深度是 1000,但我调用 501 次就不行了呢?其实原因在于 __missing__ 调用了 __setitem__, __setitem__ 又调用了 __missing__,因此每个缺失的 key 其实调用了两次,所以超过 500 就会报错。

你好,我是 somenzz,Python 的灵活程度让人发指,今天来分享一下关于字典的疯狂操作,计算斐波那契数列,话不多说,先看代码:

图片

代码定义了一个类 FibDict,继承自 dict,自定义了魔术方法 __missing__ 当 dict 查找 key失败(missing)的时候,会由 Python 解释器自行调用改方法。换句话说,如果试图从 dict 中获取不存在的 key,就会执行这个方法。

因此计算 fib_dict[10] 就会执行这个方法,计算 fib_dict[9] 和 fib_dict[8],就这样递归,一直到 fib_dict[0]和 fib_dict[1]。

这是递归,但是字典是一种 hash 表,只要计算过的数据不会重复计算,因此效率非常高。

我们可以验证下计算 fib_dict[200] 的耗时:

图片

可以看出连 1 毫秒都不到。

不过,递归虽爽,可不要贪杯哦,任何事情都有极限,1000 是递归的默认极限(sys.getrecursionlimit() ==1000),如果你直接计算 fib_dict[501] 就抛出 RecursionError 异常。

你可能有个小小的疑问,为什么递归的深度是 1000,但我调用 501 次就不行了呢?其实原因在于 __missing__ 调用了 __setitem__,__setitem__ 又调用了 __missing__,因此每个缺失的 key 其实调用了两次,所以超过 500 就会报错。

但是,字典是有记忆的,如果你这样调用它,永远不会出现递归的问题:

图片

责任编辑:武晓燕 来源: Python七号
相关推荐

2023-01-31 09:02:24

JSVMVR

2024-03-08 13:33:08

PG数据安全

2018-01-10 08:27:00

2022-09-22 14:55:31

前端JavaScripthis

2022-09-26 13:10:17

JavaScriptthis

2023-12-12 08:41:01

2022-10-24 09:57:02

runeGo语言

2010-11-23 10:21:53

跳槽

2019-06-03 10:14:07

API网关微服务

2022-06-29 08:32:04

游标MySQL服务器

2021-10-08 21:00:52

数据弱引用对象

2019-05-30 22:27:51

云计算成本云服务

2019-12-12 09:23:29

Hello World操作系统函数库

2022-03-10 08:25:27

JavaScrip变量作用域

2010-09-17 16:16:05

无线接入技术

2023-02-25 16:02:48

2021-10-19 09:21:08

AI人类工具

2020-11-23 11:04:17

Redis协议缓存

2022-09-29 15:32:58

云计算计算模式

2018-02-08 21:15:33

区块链去中心化加密货币
点赞
收藏

51CTO技术栈公众号