这两天在群里被科普了一个知识点,感觉很有意思,简单做个分享。
一直以来我都以为,实例方法隐式传入self的行为是解释器级别的特殊设计,当我们调用实例方法的时候,解释器会自动传入实例对象本身,很多文章和教程也是这么写的。虽然从结果上来讲,这个说法没有太大问题,但是严格意义上来讲,解释器并没有真正执行传入self
这个动作。隐式传入self
这个行为,仅仅是基于描述符(descriptor)的一个通用设计而已。
这两天在群里被科普了一个知识点,感觉很有意思,简单做个分享。
一直以来我都以为,实例方法隐式传入self的行为是解释器级别的特殊设计,当我们调用实例方法的时候,解释器会自动传入实例对象本身,很多文章和教程也是这么写的。虽然从结果上来讲,这个说法没有太大问题,但是严格意义上来讲,解释器并没有真正执行传入self
这个动作。隐式传入self
这个行为,仅仅是基于描述符(descriptor)的一个通用设计而已。
之前写一个小项目需要用到过期缓存功能,因为想尽量轻量一些,只在内存中进行缓存,不打算走IO。虽说Python官方的lru_cache很好用,但是偏偏又不提供过期功能。简单搜了下,发现有人提供了一个附带过期功能的版本。
最近开发项目调试的时候改用Docker来运行,主要是为了让开发环境和生产环境尽可能一致。但开发过程中很快发现一个问题,Docker构建镜像太慢了,每次改了一点代码,想要debug就得重新构建,然后要等它下载一堆依赖。开发了一天后,忍不了了,抽空查了下Docker build缓存的相关资料。
Flask和Django都是基于wsgi协议去实现的Python Web框架。本文将从与开发者相关度最高的地方入手:请求处理。
根据wsgi协议的规定,application需要提供一个callable对象给服务器(或中间件,后略),分别接收两个参数:environ字典与start_resposne函数(当然也可以是其他callable对象),这两个参数通常由服务器传入。Python官方提供了一个简单的例子:
1 | def demo_app(environ,start_response): |
前段时间学习了Docker的基本使用之后,决定借助Docker来解决麻烦的博客迁移问题。
我的博客是基于Hexo与Github Pages来实现的,属于静态博客。实际上从17年就开始折腾了,然后中途换了两次电脑,每次把npm依赖环境以及博客文件迁移到新电脑上都很麻烦。比如安装新环境,因为我不是前端,对工具不熟悉,每次都得边操作边查。装完后还得研究Hexo的配置,如果版本跟以前的不兼容的话,旧的配置文件基本就作废了,又得从头看文档。同理还得安装主题,又得把上面的问题过一遍,而且中途还会因为国内糟糕的网络环境衍生出更多烦人的问题。
所以这次决定借助docker来简化迁移流程,让自己少掉点头发。