注：本篇文章使用CPython3.6 定位参数、关键字参数在Python中，当定义一个函数时，函数接收的参数叫做为形式参数（parameters），以下简称形参；当调用一个函数时，调用者传递给该函数的值叫做实际参数（arguments），以下简称实参。 根据inspect模块的描述，Python的形参可以分成如下五类： POSITIONAL_OR_KEYWORD，默认类型，可通过定位

前言这是这个博客里第一篇带有源码Tag的文章。在过去的一个月，笔者深刻地认识到自己在技术深度方面有很大的不足，所以在未来的学习道路上，笔者会尽量多地阅读开源软件的源代码，并将自己的理解以文章的形式表达出来。如有错漏，请各位读者不吝指教。 注：本篇文章所用环境为CPython3.6 functools.wrapswraps这个内置函数装饰器在笔者的上一篇文章里有过介绍，功能很单纯（拷贝__nam

前言 读书笔记这种内容，放在Evernote等笔记软件里似乎要比放在博客里更合适。但其一是笔者还没有找到适合我的笔记同步方案，其二是博客相比笔记软件更能锻炼自身的表达能力（或许吧），其三是将读书笔记放在博客里可以避免在求职的时候被面试官吐槽博客内容太少（笑），所以还是决定将这篇文章放在博客里。 但不管怎样，读书笔记终归是读书笔记，对其他人的作用还是有限，如有读者觉得碍眼烦请无视。 注：本篇文章使

前言 嗯，怎么看怎么像标题党写的标题……其实这篇文章只是笔者对Python中引用计数、弱引用的一些记录和思考，不涉及引用循环、分代回收等概念，先打个预防针。 注：本篇文章基于CPython 3.6，可能不适用于其它CPython版本或其它类型的Python实现。 引用计数引用计数（Reference counting）可以说是一个老生常谈的问题了，炒冷饭也没啥意思。引用一下《流畅的Python

前言 在《Redis实战》这本书的第六章中，作者介绍了如何使用Redis的ZSET来实现通讯录自动补全（即前缀匹配查询）。这部分内容激发了我的兴趣，于是我借助这个机会抛出问题：如何高效地对100万个UUID进行前缀匹配，并尝试用这篇文章来解答。 数据准备首先是数据准备工作：生成100万个UUID、将其写入至Redis和MariaDB（后者可作为对比）。顺便一提，Redis和MariaDB均在笔者电

前言TTLMap是一个比较实用的数据结构，特别是在需要缓存数据的场景下。TTLMap的实现现不算复杂，但也有许多需要注意的地方，这也是这篇文章出现的原因。 在TTLMap里，移除失效的数据有三种策略：立即删除、惰性删除和定期删除策略。立即删除策略会在数据过期时立即将数据删除；惰性删除策略只在碰到过期键时才进行删除操作；定期删除策略则每隔一段时间，主动查找并删除过期键。第一种策略对CPU不友好，第二

前情提要这篇文章基于前两篇文章Django多数据库历险记（一）、Django多数据库历险记（二），将继续讲述关于Django多数据库的历险记。好吧其实这篇文章的内容已经和Django多数据库没有太大关系了……只是为了和前两篇文章的命名保持一致才取了这个标题。 秘技：避免物理外键约束 对于数据库层面的物理外键，国内互联网上的声音普遍一致，那就是不推荐使用（比如这个知乎问题），公司的DBA也持这个态度

前情提要这篇文章基于上一篇文章Django多数据库历险记（一），将继续讲述关于Django多数据库的历险记。 在上一篇文章中，我创建了一个Django项目：multi_db，在这个项目里指定了两个app：app_1和app_2，每个app下各自创建了一个Model：Model1和Model2，并为这两个app各自分配了独立的数据库db_1和db_2。历险继续～ 第三关：TestCase在multi

前言毫无疑问，Django是最优秀的Python Web框架之一，然而其对多数据库的支持却让我内心十分复杂。在数据库迁移、跨库外键、单元测试等方面，坑无处不在。于是就有了这篇文章，关于Django多数据库的历险记。 注：本篇文章使用Python 3.6+Django 2.2 准备出发 创建Django项目multi_db和两个app：app_1和app_2 1234$ django-admin

前言 在以前的文章中，我介绍了两种分析Django视图函数性能的工具：Django Debug Toolbar和cProfile中间件。在实际开发过程中，前者的SQL执行分析是相当实用的功能。 但美中不足的是，Django Debug Toolbar只能在浏览器里分析响应类型为HTML的视图函数，这就导致响应类型为JSON的视图函数必须要借助Django Rest Framework框架中的HTM