2024-11-07 08:00:00
我女儿第一天上幼儿园回来，我就拿着群里他们班级的合照，挨个问她每个小朋友都叫什么名字。一方面是想看看她集体融入得怎么样，另一方面是自己想留个底，争取每个小朋友的脸和名字都能对上。 她当然不能每个都叫出名字来，但配合群里其他家长聊天的信息，三天后我就基本能全叫出名字了。有回我正在问，丈母娘见了在旁说，「知道这个有什么用，你又不是老师。」面对这种言论，我只能一笑了之。
我觉得，总会有用的。在我看来，至少有下面几个用处：
但丈母娘这个看法就见识短浅了，她才是接送孩子的主力。我已经不知多少次听她说路上碰见个幼儿园同学，做了什么举动，却不知道是谁。
今天去幼儿园参加家长开放日的活动，其实就是小朋友在上课活动时家长在旁观看。户外休息时，很多小朋友围到我身边来，因为他们发现我能叫对他们每一个人的名字，甚至还知道小名。于是就疯狂地来考我，乐意跟我聊天。 我突然觉得，两年前做过的功课没有白做，今天派上了用场，不是什么大用，能温暖我一阵子，也足够了。
所以，你看过的每一本书，玩过的游戏，走过的路，都不会浪费。只是你还没找到用处罢了，又或者它们已经内化在你的个人气质中了。
功不唐捐。
2024-10-20 08:00:00
我一直在思考要在博客写些什么，我能写什么。刚好看到了 @laike9m 的这篇推文：
有很多观点我是不敢在网上表达的，只能和女朋友说说。有的是因为太个人化，有的是违反了普遍的认知，以及第三种情况：解释清楚要花太多时间，而我的时间本就不多。于是每次都是想想，很快便打消了这个念头了。
确实，很多时候阻挠我表达的，是四个字「大可不必」。我要表达的观点会有人认同吗？或至少，会引发一些思考吗？如果两者的答案都是否，那就「大可不必」发表了。或者即使，观点或许有一些价值，那么我要怎么表达呢？是不是得安排逻辑结构、旁征博引、收集数据案例，这些值不值得？「大可不必」，这四个字又在我脑子里冒了出来。
于是，很多想法可能就这样，只停留在了熄灯后的卧谈，甚至，更普遍的情况是，只停留在了脑海里，永远没有见天日的机会。
我们不知不觉中，给自己的表达设定了一个阈值，超过了这个值的，才会出现在对外分享的表达中。而要克服这个阈值，很需要一些能量。我死去的半导体课上学过的知识又突然袭击了我，价带电子需要一定能量，才能跃迁到导带。
所以我有时非常羡慕一些生活博主（特别是居住在国外的），坐了什么公共交通上班，吃了什么饭，日落时没云彩，下雨忘了带伞，都可以成为他们笔下津津乐道的话题。我心想要是按他们这个阈值来，那我每天不得发 24 条动态。
但有时候我又会想，大可不必。
感谢今天战胜了我的阈值的我的表达欲。
2024-07-24 08:00:00
上周末《从 21 世纪安全撤离》（后简称《21》）在深圳点映，一直很期待导演李阳的作品，距离《李献计历险记》已过去十多年了，那时房祖名还在呢。于是一出来就买了票和老婆一起去看了。看完后我和朋友聊的感想是：
我最大感想是，感谢所有资方，感谢电影工业，感谢演职人员，信任李阳，帮他完成这个作品。
没错，李阳在所有中国导演中都是一个异类，只有他能拍出这种味道的东西。怪诞、热血、信息量爆炸、莫名其妙。可以预见，这将会是一种评论两极分化的片子，密集的视效和神奇的转折之下，是破碎的剧情和二维的人物。我个人是很喜欢的，我记得在临近结尾的时候，吴晓亮演的角色在家里打《街霸》，我疯狂地扯我老婆，说这是《我爱我家》里贾家的布景啊哈哈哈，但她没什么反应。有时 GET 到了一个彩蛋，我会在内心想：这就是给我准备的啊，我懂你的梗，我厉害吧。我突然有些明白了，喜欢这部电影的会是什么人群，诚然导演是拍他自己喜欢的事物，他是个老二次元了，没有刻意要迎合谁，但这个受众人群的画像的轮廓，却渐渐在我脑中浮现了出来。我甚至于认为：
李阳这部作品等了这么久，难说不是因为这群人成为了社会中流，时机才成熟了。
这群人大概是：从小看日本动画长大、玩街机、爱摇滚、听唐朝乐队，现在喜欢二次元，喜欢上破站，喜欢宫骑英高，喜欢新民谣，喜欢万能青年旅店。
如果你全中了，可以在评论区扣个 666。问题是，这些就代表了全部的人吗？那些不喜欢这些的，看不懂《21》的，也是和我们同龄的人。我个人的话，符合 70% 吧，有些事，不喜欢就是不喜欢。我们曾认为我们是非主流，然而这已俨然成为主流，在中推、在知乎、在即刻、在小红书，到处都是同类。以至于那些对这些本不感冒的人，也硬要变成一分子，仿佛你不喜欢这些，就会被排斥在外，比之大城市的排外，有过之而不及。我不希望在这里表达对这部电影的喜欢，会排斥到了其他人。我写过《我们生活在差异里》，最后一句是：
周围的人大都是相似的，但除此之外存在着更多其他的人，我需要认清这种差异，并包容它。
所以最后，我推荐你去看这部电影，但如果你看了之后觉得不好，甚至垃圾，也欢迎你回复对这部电影的看法。
This message is used to verify that this feed (feedId:41342818704332806) belongs to me (userId:41749083576628224). Join me in enjoying RSS on the next generation information browser https://follow.is.
2024-05-30 08:00:00
:::note[版权声明] 本文谢绝一切转载，只能以链接形式分享。 :::
如同这个 Drama 的标题所写的，在我 34 岁生日这几天发生了一件非常 Drama 的事情。到现在我依然感觉有些不真实，但事情就是，我「接见」了诺贝尔奖得主。
5 月 28 日这天我收到了一封邮件。我向来习惯及时阅读新的邮件，至少是邮件的标题，所以我的邮箱从不积压未读邮件。我每天早上都会收到很多 GitHub 的通知邮件，但这一封没有 [GitHub] 的前缀， 我留了意，但也没有立刻打开阅读。可能是这个「只读标题未读内容」的行为触发了 Gmail 的机制，它把它扔进了垃圾箱。等我有空想要去读的时候发现邮件已经不见了，所幸我扫了眼垃圾箱，找到了这封邮件。
首先开头有我的称呼，然后他说自己是一位小有名气的经济学者，有维基页面。看到这我当然立即去看了一眼维基，果然有。履历中最为耀眼的，当然是 2018 年的诺贝尔经济学奖共同获奖者之一。他表明了自己的 Python 爱好者身份，联系到我是因为他刚好现在在香港，并在整个航班的时间里都在看 Python 打包的知识，认为我做的 PDM 是一个非常好的项目，想要约我见面，并表示周四（两天后）可以到深圳来。
信息量有点大，你问我有没有怀疑这是假的，我比任何人都怀疑这是假的，但开头的称呼和了解我做的项目这两点还是打消了我一半的顾虑（邮件里提到 PDM 的，至今没有一封是 spam）。另外提前仅仅两天的约见，要不是我习惯清空未读列表，否则很容易错过。至于一位功成名就的，大我 35 岁的大人物，为什么想见我这个无名氏，我相信一件事：
当佬巨到一定程度，他是向下兼容的。
我读了几遍，发现没有任何拒绝的理由，但保险起见，我还是和 yihong 一起，核实了来信地址的真实性。并且他的照片在网上到处都是，是很容易验证的。
于是我覆信表达了愿意见面，并询问对方的行程和意向的见面时间地点。关于他想来和我谈论什么我还没有想明白，但我不愿意想得太功利。如果只是谈生意和上价值，那我会有些失望。我愿意认为他只是一个年近七十的 Life Long Learner，想要和我交流一下我擅长的领域，毕竟这是他唯一能从我这里获得的了。
没想到他为了打消我的顾虑，还回信说：
Our situation may be more symmetrical than you think. I have been learning Python since 2018. I am certainly not a developer. My Python is probably worse than your English!
这也太 nice 了，什么叫向下兼容。对方这么说，翻译我是不可能翻译的，感激涕零都来不及。随后就是确定时间地点。
见面之前，他发了很长的一封信介绍他的相关背景，以及计划要谈的话题。即使地位悬殊，年龄悬殊，他依然恪守了基本礼仪，让未来的见面能顺畅进行。我不想因为他是大佬就拼命溜须，但这种谦恭的态度真的让我学到了很多。此时我已经完全不怀疑这事有假了。他不远万里从香港辗转来深圳，我这是真正的「接见」了，荣幸之至，诚惶诚恐。
我们约在了下午两点见面，作为资深 I 人，我从来不会在约定时迟到，但也绝不会提前很久到，每次都会卡得非常恰当。我算好时间出门，没想到他说行程提前了，所以可以提前到达。这表明他需要在茶馆等我一段时间，不过我没有错过约定时间，也不会特别歉疚。但这样有另外一个后果：该茶馆是预付费的，我没办法付账了。我真的是必被抢单的体质，但我想外国人不会太在意这些。
刚一见上我们就开始了对谈，可以说在整个一个多小时时间里我们连茶都没喝一口。我作为听者比较多，毕竟说也不擅长，有点像是我在采访他了。
他目前在做的有两个项目，其一是帮助 Python 初学者搭建 Python 环境的一个 GUI 应用。另一个是帮助用户生成和管理加密密钥，并进行数字签名的一个应用程序。两者都是面向初学者的简化操作和理解负担的效率工具。从这可以看出，从现在到未来一段时间内，Python 初学者仍然是一个庞大的群体，而 PEP 582 对于简化用户环境配置是一个非常好的提案。只是在 Python 论坛中讨论提案的人，还是以有经验的开发者居多，包括 PDM 的 issue tracker 中，多半也是一些有着奇奇怪怪使用场景的「高端」用户，而不是经验不足的初学者。同时我自己写的文档也不能很好的满足初学者的习惯。PEP 582 的拒绝是一件非常遗憾的事，但如果有更多初学者的声音，我相信有希望可以重启该提案的评估。
另外他还谈到了数据安全和数字签名，希望做一个面向小白的更易用的密钥管理和签名工具（gpg 太过 geek 了）。这方面我也不是很懂，主要以听为主。同时他也认为 Jupyter Notebook 在未来应该替代 PDF 成为研究论文的推荐媒介，在 Mathematica 和 Jupyter Notebook 之间推崇后者。
他非常喜欢开源，愿意为开源提供经济支持，期间还提到了 Python-Type-Challenges 这个非常适合初学者的学习项目，还以为是我的作品，我立刻做了澄清，怎能抢了 @laike9m 的功劳。
再写就变成新闻稿了，文末会附上音频转写，我想 AI 应该会比我总结得更好。让我感到敬佩的是他对很多技术细节的了解，比如他喜欢 PDM 用的 python-standalone-build 胜于 pyenv，而这是 PDM 最近才引入的一个特性。又比如他了解去年 ChatGPT 的重大事故，是 asyncio 和 redis 引起的，还想让我去 Boston College 解答 asyncio 的问题。所以啊，无论是什么牛人，都用不好 Python 的 async。
最后我邀请他到 PyCon China 来做一次演讲，我认为 Python 新手教学的话题，会是一个很有价值的输入。
见了厉害的大牛并不表示我也是厉害的大牛，但这是我第一次靠自己的工作和成就，而不是雇主的背书和推介而获得外界的认可，而且可以回应家人「你都在搞什么」这个问题，这才是真正值得我高兴的事。如果要感谢，那就感谢 Guido 吧。
2024-05-09 08:00:00
最近我写了一个 TTS(Text to Speach) 库 Tetos，为的就是统一各种云 TTS 服务的调用接口，让用户可以用同一套代码，只需要变动参数就可以在不同的 TTS 间切换。
https://github.com/frostming/tetos
在实现过程中，我翻阅了很多云 TTS 服务的接口文档，发现它们接口的设计大相径庭，有的是 RESTful，有的是伪 RESTful，有的文档里甚至只让你用 SDK，没有 HTTP 接口说明。 本来嘛，我做的工作就是让用户可以不用做这些工作，但本篇文章还是想主要吐槽一下火山引擎的接口，和它的 SDK 设计。所以这篇可能不能叫《友好的 Python》了，可以当吐槽大会来看。
假设你是一名公有云厂商 Python SDK 的开发者，你们的接口有一个非常复杂的验签机制，你人微言轻，不能质疑，只能按照上面交给你的文档来做。那么你会怎么设计这个 SDK 给用户使用？ 进一步，不如我们脱离签名的具体细节，把它抽象出来：
sign(request, randomData, secrets) -> signedRequest
签名的输入有三个：HTTP 请求、现场随机生成的数据，和密钥数据。输出是签名的请求，这个签名可能修改了请求头，或是请求体，我们不管它，总之后续就用这个新的请求执行。
假如这个 SDK 支持的是 requests 库，你会怎么设计呢？不妨先带着这个思考，来~吃一口屎~看一下火山引擎的 SDK。
下面的代码是我直接从火山引擎的接口文档里截取的。
class SAMIService(Service):
_instance_lock = threading.Lock()
def __new__(cls, *args, **kwargs):
if not hasattr(SAMIService, "_instance"):
with SAMIService._instance_lock:
if not hasattr(SAMIService, "_instance"):
SAMIService._instance = object.__new__(cls)
return SAMIService._instance
def __init__(self):
self.service_info = SAMIService.get_service_info()
self.api_info = SAMIService.get_api_info()
super(SAMIService, self).__init__(self.service_info, self.api_info)
@staticmethod
def get_service_info():
api_url = 'open.volcengineapi.com'
service_info = ServiceInfo(api_url, {},
Credentials('', '', 'sami', 'cn-north-1'), 10, 10)
return service_info
@staticmethod
def get_api_info():
api_info = {
"GetToken": ApiInfo("POST", "/", {"Action": "GetToken", "Version": "2021-07-27"}, {}, {}),
}
return api_info
def common_json_handler(self, api, body):
params = dict()
try:
body = json.dumps(body)
res = self.json(api, params, body)
res_json = json.loads(res)
return res_json
except Exception as e:
res = str(e)
try:
res_json = json.loads(res)
return res_json
except:
raise Exception(str(e))
if __name__ == '__main__':
sami_service = SAMIService()
sami_service.set_ak(ACCESS_KEY)
sami_service.set_sk(SECRET_KEY)
req = {"appkey": APPKEY, "token_version": AUTH_VERSION, "expiration": 3600}
resp = sami_service.common_json_handler("GetToken", req)
try:
print("response task_id=%s status_code=%d status_text=%s expires_at=%s\n\t token=%s" % (
resp["task_id"], resp["status_code"], resp["status_text"], resp["expires_at"], resp["token"]))
except:
print("get token failed, ", resp)
这是一个获取 Token 的请求，最后使用的是 common_json_handler() 这个函数。一眼看去，你发现一点都不像正常的 Python HTTP 调用风格，你以为他是祖传自建的 HTTP 轮子，但其实不是，它底层还是 requests，那么为什么 SDK 会变得这么畸形呢？
我们先忽略 set_ak(), Singleton 这种从别的语言过来的在 Python 里毫无必要的写法，并且也忽略他在 except Exception 逻辑里返回正常响应的行为（我得咬着后槽牙才能忍，这么写是要浸猪笼的）。
我第一个反对的是，为什么要用继承 + staticmethod 的方法来写，我们知道 Python 里用 class 基本是要共享状态的，而用了 staticmethod 就没得共享了，那么为什么不能直接改成下面这样？
api_url = 'open.volcengineapi.com'
service_info = ServiceInfo(
api_url, {},
Credentials('', '', 'sami', 'cn-north-1'), 10, 10
)
api_info = {
"GetToken": ApiInfo("POST", "/", {"Action": "GetToken", "Version": "2021-07-27"}, {}, {}),
}
sami_service = Service(service_info, api_info)
...
并且阅读代码可知 Credentials 的头两个参数就是 access_key 和 secret_key，那么直接传入，不必后面再 set_ak 了。上面这个写法和之前继承 + staticmethod 的效果完全一样。
好了现在除了 common_json_handler() 以外这个类的成员全被我干掉了，需要注意到 api_info 里仿佛包含的是一些请求相关的信息，依次分别是 method, path, body 和 headers 之类的东西。下面我们来看看怎么改掉这个函数。
common_json_handler() 唯一用到的 Service 的方法是 self.json()，从名字猜测这是一个接收 JSON 响应的方法，注意到 body 和 response 都分别经过了 json.dumps 和 json.loads，等于这个名为 json() 的函数啥事都要自己来干。既然如此不要把它放在类里面了，直接拉出来写成一个函数。
def common_json_handler(service, api, body):
params = dict()
try:
body = json.dumps(body)
res = service.json(api, params, body)
res_json = json.loads(res)
return res_json
except Exception as e:
# 后面的太可怕了，不要学
...
还记得直接用 requests 怎么发送和接收 JSON 响应吗？
res = requests.post(url, json=body)
res_json = res.json()
好优雅，好舒服，这么优雅舒服的库怎么被他包成了这样？不要忘了一开始提出的问题，要对请求签名。我们看看 Service.json() 的实现。
def json(self, api, params, body):
if not (api in self.api_info):
raise Exception("no such api")
api_info = self.api_info[api]
r = self.prepare_request(api_info, params)
r.headers['Content-Type'] = 'application/json'
r.body = body
SignerV4.sign(r, self.service_info.credentials)
url = r.build()
resp = self.session.post(url, headers=r.headers, data=r.body,
timeout=(self.service_info.connection_timeout, self.service_info.socket_timeout))
if resp.status_code == 200:
return json.dumps(resp.json())
else:
raise Exception(resp.text.encode("utf-8"))
好家伙，难怪我要自己 json.loads() 呢，json.dumps(resp.json()) 来来来，你过来我保证不打死你。
接着看，这里出现了关键的 SignerV4.sign()，参数是一个自己生成的 request 对象，和上面我抽象的差不多，需要一些请求的信息和密钥。这也是为什么要一个如此奇怪的 api_info，因为这是签名需要用的请求的信息，只好单独传递。好了问题找到了，搞这么奇怪，就是因为他自己弄了个请求对象，然后又要费劲把它变成 requests 接受的对象（r.build() 拿 URL 及 r.headers, r.body）。那么请问下，为什么不能用 requests 内部的请求对象去生成签名？反正最终是要靠 requests 发送请求，要有的信息这全都有。就好比你跑马拉松，补给点都是在跑道必经之处，想象一下你要喝个水还要专门跑岔路去补给点，怎生一个卧槽。
尽量不要自己封装新的对象，因为你要拷贝原有的属性。
那么现在要做的事情就清楚了，就是要在请求前修改 requests 即将要发送的请求对象，给它加上签名信息。这其实是一种 interceptor，requests 有什么机制实现这个需求呢？
我第一想到的是 Event Hook，但仿佛 requests 没有 before_request 这个钩子（曾经有），那么接下来考虑的是重载，由于这个签名方法是应用在 request 对象上的，所以不同在 get，post 之前做文章，因为这两个方法都还没产生 request 对象呢，可以重载 Session.send() 这个方法：
class VolcSession(requests.Session):
def send(self, request, **kwargs):
# new_sign 具体实现略，照抄即可
new_sign(request, service_info, credentials)
return super().send(request, **kwargs)
（重载 Session.prepare_request() 也是一样的效果，区别是在 super() 返回的对象上修改）不知对开始的问题你们心目中的方案是不是这样。
但是，我说但是了，这里最好的方法利用，requests.auth，他的签名是这样的：
class AuthBase:
"""Base class that all auth implementations derive from"""
def __call__(self, r):
raise NotImplementedError("Auth hooks must be callable.")
接收一个唯一对象 r，这个就是即将要发送的请求，并返回一个新的请求，你可以对它作任何修改，这不就是我们要做的事情吗？签名所需的其他信息，可以作为 __init__ 的初始化参数。那么就可以改写成：
class VolcAuth(AuthBase):
def __init__(self, service_info, credentials):
self.service_info = service_info
self.credentials = credentials
def __call__(self, r):
# new_sign 具体实现略，照抄即可，区别是自定义的 request 对象改成了 requests 的
new_sign(r, self.service_info, self.credentials)
return r
只需要这一个小小的对象即可。利用库的已存在的数据结构的好处是，我们能最大化保持原来的库的接口，因为请求方法我们没有任何侵入。用这个 Auth 对象请求的方法是：
auth = VolcAuth(service_info, credentials)
res = requests.post(url, json=body, auth=auth)
这样 post() 方法里的所有参数，包括 data, files, headers 你可以任意使用，就像用 requests 一样去调火山的接口，你还可以把创建一个带 auth 的 Session，这样后面调用就不用每次都传 auth 了。无感亲肤，就像冰丝内裤一样。
对一个库的重载或修改，修改面要越小越好，并尽可能利用库本身提供的扩展方式。
这与上面的方案相比，上面需要继承 Session，而利用的 AuthBase 本来就是提供给你扩展的，而且创建的对象 Auth 比 Session 小得多。只有当库扩展能力不足时，才考虑前面的方式，一直到无能为力，甚至动用 monkey patch 这种武器。
这里面的细微优劣，就像你想要车的某个高级功能，你是希望得到一个插到任何车上都能用的零件，还是一台升级好的车，且你不知道它改了哪里呢？
我在 Tetos 里做了一个针对 httpx 的 Auth 实现，和 requests 的 Auth 作用差不多，有兴趣的话甚至可以用一个 Auth 同时支持 httpx 和 requests 两个库。
https://github.com/frostming/tetos/blob/15a039f15feda2a3f7ffba7c441b5438f22a6ee4/src/tetos/volc.py#L25-L86
比较一下，这个实现 62 行，加上不超过两行的调用，实现了原来 SignerV4.py 207 行，加上 Service.py 290 行，近 500 行，还没算上 import 的公共函数，十倍的差距。可见阅读库的文档，理清逻辑，是可以大大节省代码量的。
这个 SDK 写成这样，可能是直接从别的语言直译过来的。不知从事 code review 的 @piglei 如何看待，能不能过你这关。如果阅读本文的你恰好就是维护这个 SDK 的人被我中伤了我深表抱歉，并绝对不改。
