Python

TL;DR：Python工具多年来一直是支离破碎且缓慢的灾难。革命没有来自生态系统内部：它来自Rust。uv、Ruff和ty——都由Astral用Rust编写——已经取代了半打工具，速度提升了10倍到100倍。看来Ferris信徒们还是有道理的。 你有没有试过向别人解释如何在Python中安装依赖？ “用pip。不过，要在virtualenv里面。或者用venv，这是新的。如果你有多个Python版本，需要用pyenv。管理项目的话，用poetry。或者pipenv。或者pdm。如果做数据科学就用conda。啊，lock文件每个工具都用不同的格式生成。别忘了setup.py。嗯，现在是pyproject.toml了。不过，有时候两个都要。” 如果这听起来很熟悉，你并不孤单。Randall Munroe在2018年为此专门画了一期xkcd漫画——一个意大利面条图，展示了Python在你机器上可能的所有安装方式。八年过去了，这期漫画依然贴切。或者说，直到最近还是这样。 工具墓地 让我们盘点一下。在2024年之前，要搭建一个"现代"Python项目，你至少需要从这些工具中组合选择： 工具 功能 pip 安装包 virtualenv / venv 隔离环境 pyenv 管理Python版本 poetry / pipenv / pdm 依赖管理和lock文件 flake8 / pylint Linter black / autopep8 格式化工具 isort 排序导入 mypy / pyright 类型检查 至少八个工具——而在其他生态系统中这只需要一两个工具。每个都有自己的配置、配置文件，以及与其他工具的不兼容性。在pyenv创建的virtualenv中安装poetry，而pyenv又使用Homebrew安装的Python，而Homebrew又有另一个全局pip…好吧，你懂的。 最糟糕的是：每隔几年就会出现一个新工具，承诺统一一切。Pipenv曾经要成为解决方案。然后是poetry。然后是pdm。xkcd的标准化漫画在循环上演：“我们有14个工具，这太荒谬了。我要创建一个统一工具。现在我们有15个工具了。” 然后螃蟹来了 2022年，一个叫Charlie Marsh的人——Khan Academy和Spring Discovery的前员工——发布了一个叫Ruff的Python linter。用Rust编写。 Python社区的反应可想而知：“太好了，又一个linter。“直到他们看到数据。Ruff比Flake8快10到100倍。不是快20%。不是快一倍。**快一百倍。**在大型代码库中，原本需要30秒的linting现在只需要300毫秒。 但Ruff不满足于只做一个快速linter。它吞并了Flake8、Pylint、isort和Black。一个工具，一个二进制文件，零Python依赖。它做linting、格式化、排序导入。而且速度如此之快，你可以在编辑器的每次按键时运行它而不会感觉到延迟。 Charlie创立了Astral来为项目提供架构。他招募了有趣的人才：团队中有ripgrep、bat和hyperfine的作者——这些用Rust编写的终端工具已经证明了用Rust重写经典工具不是在开玩笑，而是客观的改进。 uv：让pip看起来像拨号上网 2024年2月，Astral投下重磅炸弹：uv。一个Python包和项目管理器。用Rust编写。 简单说：uv替代了pip、pip-tools、pipx、poetry、pyenv、virtualenv和twine。全部。一个二进制文件。 我知道你在想什么：“好吧，又一个声称替代一切的工具。“但数据简直不可思议： 操作 pip uv 速度提升 安装依赖（无缓存） ~30s ~0.3s 100x 解析依赖 ~15s ~0.15s 100x 创建virtualenv ~2s ~0.01s 200x 安装（有缓存） ~5s ~0.05s 100x 这不是合成基准测试。这是你在日常工作中能感受到的。原本让你有时间去倒咖啡的pip install现在在你按下回车之前就完成了。 ...

上周，我在用 Instruments 工具对一个 Swift 应用进行性能分析。没什么稀奇的：运行 xctrace record，再运行 xctrace export，然后把导出的 XML 拷贝到 Claude Code 的上下文，让它帮忙分析热点。 结果 Claude 跟我说："XML 文件太大，无法可靠地处理。" 33,553 行 XML，只为分析一个只有两个函数的程序。 真正的问题 xctrace export 是一个很棒的工具。它什么都给你：每一个采样点、每一个调用栈、每一帧的二进制信息、内存地址、UUID，简直面面俱到，精准无比，完美无缺。 但问题，也正是源于它的完美无缺。 对一个应用程序进行性能分析时，我并不需要所有的 3,044 个细节采样点。我不需要知道第 1,847 个采样点在 00:02.847.882 捕捉到了 libswiftCore.dylib 内存地址为 0x1027ec9a8 的内容。我只需要知道 heavyWork() 花掉了 70% 的时间，而 lightWork() 只用了 30%。 用大白话来说：我需要的是 10 行总结，而不是 33,000 行繁文缛节。 为什么 XML 格式是正确的选择（但噪音不可取） 在有人提出“2026 年了还用 XML 才是问题”之前——并不是这样。 XML 对于 xctrace 的功能来说，是非常理想的格式。试想一下： 层次结构：一个调用栈是一个框架的树状结构。一个采样点包含了一个调用栈，一个线程，一个进程。XML 自然而然地可以建模这些内容。 自描述性：每个元素都有名字、带类型的属性，并且结构可以被验证。你不用去猜 CSV 第七列的内容代表什么。 优雅的去重：xctrace 使用了 id 和 ref 系统，首次定义一个框架时是这样的：id="59" name="heavyWork()"，后续只需引用 ref="59"。可以看作是一种序列化的 flyweight pattern。 可以用标准工具解析：XPath、xmllint、xml.etree.ElementTree…… 不需要专属解析器。 xctrace 的 XML 格式并不是冗余。它是 Instruments 所需的结构化信息，用来重建交互式调用树、对比运行情况，以及按线程和进程进行筛选。它是专门为一个可以展开和折叠节点的 GUI 工具设计的。 ...

“你知道 Rust 最棒的一点是什么吗？它不会允许你编译粗制滥造的代码。你知道最糟糕的一点是什么吗？起初你写的所有代码都是粗制滥造的。” —— 蟹老板，大概是这样说的 比一个 AI 代理更好的是什么？是一个用 Rust 重写 的 AI 代理。 如果你上网超过五分钟，就会知道这个梗。不管是什么项目：文本编辑器、DNS 服务器、BMI 计算器，总会有人跳出来评论“你应该用 Rust 重写它”。这就是 Rewrite It In Rust —— 简称 RIIR，和地心引力一样不可避免的存在。 好吧，那我就来做一次真的。我将把一个有 8,300 行代码的 Python AI 代理移植到 Rust。但不是因为这个梗在召唤我（嗯…有一点是因为它）。我这么做，是因为我需要一个实验对象。 论点 最近几周，我一直在写关于静默失败、五种防止幻觉的方法、以及"一个 LLM 如何生成看似正确但实际上错误的代码"的文章。我甚至还给它起了个名字：对抗性开发。永远不要相信，总要验证。 很多理论，是时候实践了。 于是，我需要一个项目，满足三个特点：范围适中（而不是一个需求会不断变化的新应用）、明确的真相来源（现有可用的 Python 代码）、以及足够的复杂度，让 LLM 的幻觉能“藏起来”。一个纯粹的移植可以完全满足这三点。输入和期望输出已然存在。如果 Rust 版本的行为和 Python 的不完全一样，那肯定有问题。就是这么简单。 既然要做移植，那为什么不顺便真正学学 Rust 呢？借用检查器 (borrow checker)、所有权 (ownership)、生命周期 (lifetimes)… 我读了好几年资料，却几乎没有亲自实践过。如果是写一个真实项目而不是第 N 次看教程，一切或许会大不相同。 目标对象 它的名字叫 nanobot。这是一个基于 OpenClaw 开发的个人 AI 代理。它能将各种 LLM（如 Claude、GPT、DeepSeek）接入聊天渠道——Telegram、Discord、Slack、电子邮件——并赋予它们更多功能。比如读取和编辑文件、执行命令、网络搜索、通过 cron 编排任务，甚至在对话之间保存记忆。 它可以正常工作。而且已经运行了几个月。在 Python 上。 问题呢？它是单线程的。一次只能处理一条消息。如果你连续发送三条信息，它会像周六中午的超市购物队伍一样排队等待。它的内存消耗约为 50MB，而它实际上只是在不同的 API 之间传递 JSON。此外，它的错误处理方式令人羞愧：到处都是return f"Error: {str(e)}"。 ...

性能问题的觉醒 你在数据科学项目上工作了一段时间。手头有二十多个笔记本文件、几张图片，还有三个月前看起来还不错的文件夹结构。 当你执行git status查看修改时…等待。继续等待。在等待的过程中你甚至怀疑电脑是卡死了还是在冥想。 剧透：它没在冥想。它在煎熬。 问题是有名有姓的 Git本身并不慢。慢的是你的仓库。 执行git status时，git需要做两件看似简单实则不然的事： 扫描整个文件树检查变更 逐个general比较文件与暂存区的差异 普通仓库中这个过程是瞬时的。但Jupyter笔记本本质上是伪装成文档的JSON文件——而且不是普通JSON：它包含了代码、输出结果、base64编码的图片、内核元数据，基本上囊括了设计者能想到的所有内容。 一个包含少量图表的"小型"笔记本可能就有几MB。乘以二十个笔记本，你就得到了一个每次查看都要呻吟的仓库。 如果你还重命名了文件夹…git会理解为"删除了50个文件并新增了50个文件"。保证让你’爽’到极致。 方案一：给仓库装个门卫 第一个解决方案优雅得让人懊恼为什么没早点知道西门庆。 FSMonitor的工作原理：不再让git每次扫描整个仓库，而是由操作系统主动通知哪些文件发生了变化。 说白了：就像是门口有个门卫告诉你"只有老张进来了"，而不必每次核对全量宾客名单。 启用方法： git config core.fsmonitor true git config core.untrackedcache true 完成。就这么简单。 初次启用后的第一次西git status可能耗时相当(甚至更长，因为要初始化缓存)。但从第二次开始…魔法降临了。 在我的400+文件仓库中，git status从2- períodos3秒变成了真正的瞬时完成。不是"变快了"，是真正的心念电转。 兼容性如何？ macOS: 支持，使用FSEvents Linux: 支持，使用inotify(只要内核支持) Windows: 支持，使用ReadDirectoryChangesW 所以说，全平台通用。 方案二坏人保存菜谱而非成品照片 FSMonitor加速了扫描过程，但西存在另一个问题：笔记本文件依然庞大。每次执行单元格并保存时，即使代码相同文件内容也会改变，因为输出结果不同。 这意味着： 不可读的diff(谁想看图片的base64?) 膨胀的commit 地狱级merge 解决方案叫nbstripout，人如其名：在提交前剥离笔记本的输出内容。 这好比保存菜谱但不保存成品照片。代码得以保留，结果可以随时重新生成。 使用uv安装： uv add nbstripout uv run nbstripout --install 或用传统pip： pip install nbstripout nbstripout --install --install参数会自动配置git过滤器。此后提交笔记本时都会自动剥离输出。 验证是否生效： git config --get filter.nbstripout.clean 若返回类似nbstripout Ressource则配置成功。 需要保留输出怎么办？ 好问题。有时你需要提交已执行的笔记本，比如用于文档或让他人直接查看。 ...

问题：教授概念前提前使用 我有一门包含47节课的编程课程。每节课都有笔记（用来解释概念）以及实验室任务（供学员练习）。然而，我有一个问题：有时我会在实验中使用尚未在笔记中解释过的概念。 “好吧，在这个练习中使用 map 来转换列表。” 问题是什么？直到三节课后，我才开始解释 map 的含义。 这种问题比你想象中更常见。因为我对教学内容非常熟悉，经常跳跃思路，可能在无意间假设学生已经理解了一些我还没有实际讲到的概念。结果导致学生感到非常困惑和沮丧，他们认为自己不够聪明，但真正需要改进的是老师的教学大纲。 手动解决方案是检查每个实验室任务，列出所使用的概念，并验证这些概念是否已被教学过。然而，我的课程有47节课，每节课有多个Notebooks。手动搞定显然不是办法。 解决方案：使用 ChromaDB 实现语义搜索 解决方案其实很简单： 从每个 Notebook 中提取概念（包括教学和使用的概念） 将这些概念存储到一个能够处理“意义”、不仅是文本的数据库中 对实验室任务中使用的每个概念，验证其是否已在之前的笔记中介绍过 这个“处理意义”是关键。如果在笔记中我提到了“高阶函数”，而在实验室任务中使用了“higher-order function”，普通的 grep 是无法匹配到的。但从语义上来说，它们是相同的。 这就是 ChromaDB 派上用场的地方：这是一种将文本转化为嵌入向量的向量数据库，并支持基于相似度的搜索。简单来说，你可以将文本存储进去，然后问它“有没有类似这个的东西？”它会返回最相似的内容。 五分钟了解 ChromaDB ChromaDB 就像是用于嵌入向量的 SQLite。一个单独的文件（或文件夹），无需服务器部署，也不需要复杂的配置。安装后即可直接使用。 pip install chromadb # 如果你使用 uv： uv add chromadb 基础概念 在普通的关系型数据库中，你存储的是行和列。而在 ChromaDB 中，你存储的是带有 嵌入向量 的 文档： import chromadb # 创建客户端（支持磁盘持久化） client = chromadb.PersistentClient(path="./mi_db") # 创建“集合”（类似于表） collection = client.get_or_create_collection( name="conceptos", metadata={"hnsw:space": "cosine"} # 使用余弦距离 ) # 存储文档 collection.add( ids=["c1", "c2", "c3"], documents=["纯函数", "for 循环", "递归"], metadatas=[ {"clase": "class_010", "tipo": "notes"}, {"clase": "class_015", "tipo": "notes"}, {"clase": "class_020", "tipo": "notes"} ] ) 就是这样。ChromaDB 会自动： ...