PyTexas 2026 回顾

# PyTexas 2026 回顾 Source: https://bernat.tech/posts/pytexas-2026-recap/ PyTexas (https://www.pytexas.org/) 是每年在德克萨斯州奥斯汀举办的 Python 会议。2026 年的会议于 4 月 17 日至 19 日在奥斯汀市中心的 Austin Central Library (https://library.austintexas.gov/central-library) 举行。 一句话总结：PyTexas 2026 于 4 月 17 日至 19 日在奥斯汀举办。周五是教程日，周六和周日是演讲环节，包含两场主题演讲和两轮闪电演讲。几个主题在不相关的演讲中反复出现： - **刻意设计。**贯穿两场主题演讲的主线。Hynek Schlawack：领域模型就是*"the precious"*——先设计它，再在边界处进行转换。Dawn Wages：对技术栈的掌控是她提出的模型与职业专业化三大支柱之一。 - **Agent 应该写代码，而不是决定写什么。**Peter Sobot 的《Seven Stages of AI Grief》以这句话收尾。Al Sweigart 认为 "agentic engineering" 不过是 vibe coding 的更好听的说法，而且 almost-right 比 wrong 更糟。Maria Silvia Mielniczuk 的 MCP 演讲将同样的理念构建成了一种架构：模型只负责建议，只有服务器执行。Adam Gordon Bell 的跑步教练把确定性工作（纯 Python）与解释性工作（LLM）分开。周日的开场演讲直言不讳：当 AI 提交了一个糟糕的 PR，要修复流程，而不是修复模型。 - **代码质量是 AI 生产力的输入。**Miguel Vargas 的框架：在已经干净、安全且有类型的代码库中，AI agent 能产生更干净、更安全的代码，因此 Ruff、ty 和 uv 现在比以往更重要。 - **供应链仍然是攻击面。**Christopher Ariza 解释了为什么 `pip install` 仍在运行任意代码，`.pth` 文件、`sitecustomize.py` 和 `setup.py` 是需要特别关注的具体位置。 - **CPython 本身正在变得更快。**Jacob Coffee 介绍了 PEP 810 (https://peps.python.org/pep-0810/) 的懒加载导入（lazy imports）以提升启动速度；Charlie Lin 讲解了 free-threaded 构建以及如何让扩展模块在其下安全运行。 本文按日程顺序详细介绍了我参加的每场演讲的要点。 PyTexas 2026 周边：一只戴着牛仔帽和德州旗方巾的黄色橡皮鸭 PyTexas 2026 开幕致辞，现场有充气 Buc-ee 吉祥物 ## 周五Link to heading (https://bernat.tech/posts/pytexas-2026-recap/#friday) 周五是教程日。**Heather Crawford** 上午讲授了 *Import is Important: The Secret Life of Python Modules and Packages*，我下午讲授了 *Becoming a Better Python Developer with AI* (https://www.pytexas.org/2026/schedule/)。幻灯片地址：gaborbernat.github.io/py-texas-26-workshop (https://gaborbernat.github.io/py-texas-26-workshop/)。我计划在未来几周内将我的教程单独写成一篇更详细的帖子。 ## 周六Link to heading (https://bernat.tech/posts/pytexas-2026-recap/#saturday) ### Dawn Wages 主题演讲：Fine-Tune Your FutureLink to heading (https://bernat.tech/posts/pytexas-2026-recap/#dawn-wages-keynote-fine-tune-your-future) 副标题：*职业与模型专业化之我见*。 Dawn Wages 关于职业专业化的演讲幻灯片 Dawn（Anaconda (https://www.anaconda.com/) 社区与开发者关系总监，前 PSF 主席）开场先对 AI 生产力的叙事提出了警示：加州大学伯克利分校的早期研究表明，AI 加剧了工作负荷，而非减轻。更低的启停成本意味着任务碎片化，并侵占大脑所需的休息时间。她提醒观众喝水。 这场演讲将**实验循环**设定为工程师、研究人员和科学家的基础心智模型：计划 → 设计 → 构建 → 测试 → 发布，这是一场对话，而非线性路径。专业化是你通过足够刻意地运行这个循环所解锁的回报。 她的类比贯穿了整场演讲：LLM 专业化与职业专业化是同一套形状。 `` flowchart LR classDef model fill:#DBEAFE,stroke:#1E40AF,color:#1E3A8A; classDef career fill:#FEF3C7,stroke:#B45309,color:#78350F; P[Pre-training]:::model --> F[Fine-tuning]:::model --> S[Specialized prompting]:::model GE[Gen. education]:::career --> CS[Core skills]:::career --> EX[Experience]:::career --> AT[Adv. training]:::career --> SP[Specialization]:::career --> AP[Application]:::career --> MA[Mastery]:::career `` Scaling laws 表明，更大的模型持续改进，而小语言模型很快达到瓶颈，因此让能力匹配问题比盲目追大小更重要。同样的回报 U 型曲线也适用于人类努力。 她认为**本体论（ontology）**是让模型和职业都能复利增长而非盲目扩张的杠杆。本体论比语义学更进一步：语义学问的是一个词在语境中意味着什么（"sidecar" 可能是一种饮料、摩托车边车或 Azure 组件），而本体论则正式定义了存在哪些实体、它们如何关联、以及受什么规则支配。知识图谱领域的工具（OWL (https://www.w3.org/OWL/)、RDF (https://www.w3.org/RDF/)、SPARQL (https://www.w3.org/TR/sparql11-overview/)、triple stores）支撑了这一点，而在多 agent 系统中，本体论对于 agent 之间的语义一致性变得至关重要。 她梳理了模型侧的专业化技术：**LoRA** (https://arxiv.org/abs/2106.09685)（Transformer 层内的小型适配器）、full fine-tuning、参数高效方法、本体论驱动的数据清洗、world models（预测下一个*状态*而非下一个词）、**RAG**（retrieval-augmented generation）以及 SLM 优化（知识蒸馏、剪枝、量化、定向微调）。 然后她将每一项映射到职业发展的三大支柱下： 1. **Efficiency through expertise。**帕累托 80/20 法则：专注于能带来 80% 结果的 20% 技能。个人知识库就是你职业生涯的 RAG。教学即蒸馏（重复解释，深化掌握）。剪枝低价值任务，要求管理者明确说出什么才算有价值。通过相邻领域的小型模块化学习获得领域灵活性。 2. **Small iterations, big wins。**频繁的 check-in 会产生复利。设计能给你定期反馈的工作流，而不是攒到一次大交付。 3. **Ownership over your stack。**在软件中：你的工作流、数据、模型和基础设施。在职业中：你的收入、声誉、人脉和技能。她倡导 local-first AI，并驳斥了"你需要一台 Mac Mini"的条件反射：关键在于一个有明确边界的可控环境，而非硬件。 她最后将专业化重新定义为**"战略性无知的艺术"**：刻意选择*不*去了解什么，这样你才能设定边界、深化专长、保护精力。Scaling laws 同样适用于人类：平衡技能（规模）、经验（数据）和精力/时间（算力）。"放轻松"这类 burnout 建议出于善意，但在现实压力下显得天真。建立支持性社区（她称之为"战友式朋友"）。 幻灯片：dawnwages.info/pytexas-keynote-26 (https://dawnwages.info/pytexas-keynote-26/)（也可通过 bit.ly/pytexas-keynote-26 (https://bit.ly/pytexas-keynote-26) 访问）。 ### Moshe Zadka: Python as Your DSLLink to heading (https://bernat.tech/posts/pytexas-2026-recap/#moshe-zadka-python-as-your-dsl) Moshe 的论点：只要设计得当，*任何* Python 代码都可以充当领域特定语言。失败模式是构建"伪 Python"：通过运行时魔法破坏 Python 规则的系统。 早期 Django 就是这样做的：当你声明 `ForeignKey` 时，它会注入 `book_set` 之类的名字，隐藏全局 `db` 对象，并创建在源代码中不可见的反向关系。编辑器和 linter 无法解析它们，测试在框架外运行时会失败，pickle 失败因为类没有附加到模块上，用户也无法信任自省。 Django 最终为此进行了一轮*magic removal*。 **为什么魔法有害：** - **破坏工具和可发现性。**IDE 无法解析注入的名字。Ctrl+点击失效。Linter 跟你作对。 - **损害可复用性。**在 DSL 内部编写的代码通常无法在框架外复用（包括测试）。 - **阻碍调试。**`print` 和 `logging` 变得不可靠。Pickle 损坏。 - **让经验丰富的 Pythonista 感到意外。**"人们会假设他们可以做所有在 Python 里能做的事，但他们做不到。" 更好的路径是成为有效、地道 Python 的 DSL。Moshe 的例子： - **NumPy** (https://numpy.org/)：很少有人称它为 DSL，但切片语法（`x[0, ..., -1]`）、广播和运算符重载（`+`、`*`、`@`）使其成为 DSL。它的影响力大到让 `...` 变成了语言字面量。所有标准 Python 工具（调试器、性能分析器、IDE、测试运行器）都对它有效。 - **Stan**：基于上下文管理器和可调用对象构建的 HTML/XML 构造 DSL。`with tag('html'): with tag('body'): ...` 使用普通的 `with` 块构建树，没有魔法导入，且调试器可用。 - **现代 Django** (https://www.djangoproject.com/) 模型：类属性代表数据库列。库仍在底层使用元类，但接口是透明的：拼错关系名会在导入时报错。 - **Pyramid** (https://trypyramid.com/) 路由：`@view_config(route_name='home', renderer='string')` 作为函数装饰器。配置器扫描带装饰器的函数来组装应用，这保持了路由的可发现性和可测试性。 **无需魔法就能完成工作的技术：**dunder 方法（`__call__`、`__getitem__`）提供运算符风格的人机工程学，装饰器用于声明式配置，上下文管理器用于嵌套作用域，生成器用于惰性流，元类用于在类创建时介入（谨慎使用）。 对于插件发现，优先使用 `importlib.metadata.entry_points` (https://docs.python.org/3/library/importlib.metadata.html) 或 `pluggy` (https://pluggy.readthedocs.io/)，而非全局注册副作用。 **Moshe 的 Pythonic DSL 原则：**要求显式导入，保持可发现性（jump-to-definition 必须可用），支持标准测试和调试，利用熟悉语法而非自定义解析器，从小处开始并允许用户在 DSL 不够用时回退到纯 Python，不要让懂 Python 的人感到意外。 当用户通过相同的三四种模式反复与你的系统交互时，构建 DSL。对于一次性或高度多变的任务，跳过它。 ### Adam Gordon Bell: I Built an AI Running Coach (That Actually Remembers My Training)Link to heading (https://bernat.tech/posts/pytexas-2026-recap/#adam-gordon-bell-i-built-an-ai-running-coach-that-actually-remembers-my-training) Adam Gordon Bell 的 2025 Monster of Mazinaw 10K 成绩幻灯片 Adam（Pulumi (https://www.pulumi.com/) 社区工程师）打造了"Momentum Bot"，为了在 2026 Monster's Mazinaw 30K 中击败他的朋友 Malcolm。这是一场穿越加拿大地盾（Canadian Shield）的超马。他的幻灯片展示了 2025 年 10K 成绩：Malcolm Clarke 第 12 名，Adam Bell 第 25 名。 之前的尝试都失败了，因为他每年赛前只训练几个月；这次他承诺打造一个能全年训练他的教练。 **架构。**Strava (https://www.strava.com/) → AWS Lambda (https://aws.amazon.com/lambda/)（定时任务 + webhook）→ DynamoDB (https://aws.amazon.com/dynamodb/)（结构化跑步数据）→ S3 (https://aws.amazon.com/s3/)（原始归档）→ Slack (https://slack.com/)。Peloton (https://www.onepeloton.com/) 没有公开 API，所以他的 Lambda 用刷新的 JWT 抓取 Peloton 账户。 `` flowchart LR classDef input fill:#DBEAFE,stroke:#1E40AF,color:#1E3A8A; classDef compute fill:#FEF3C7,stroke:#B45309,color:#78350F; classDef store fill:#E5E7EB,stroke:#4B5563,color:#1F2937; classDef output fill:#DCFCE7,stroke:#15803D,color:#14532D; Watch[Fitness watch]:::input --> Strava:::input Peloton[Peloton web UI]:::input -- JWT scrape --> Lambda[AWS Lambda]:::compute Strava -- webhook --> Lambda Cron[Daily cron 6am]:::input --> Lambda Lambda --> Dyn[DynamoDB]:::store Lambda --> S3[S3 raw archive]:::store Lambda --> LLM[LLM interpretation and motivation]:::compute LLM --> Slack:::output `` 数据以每秒粒度从多个来源（运动手表、Peloton、踏频传感器）到达，经时间戳对齐并归一化为逐秒列式格式，再汇总为每次活动的统计：心率区间时间、平均坡度、踏频、功率和心率趋势。 **他反复强调的分界。**确定性工作（距离、配速、平均值）保留在纯 Python 中。LLM 只处理他原本需要用眼睛看数据才能做的事：解读、激励和自适应反馈。这降低了成本，并让系统可预测。 **训练理念。**Polarized training：80% 低强度（Zone 2）用于耐力和防伤，20% 高强度（Zone 4+）用于速度。周三跑三次，周末一次长跑，一次力量训练。计划随季节调整（秋季堆量、冬季跑步机、春季越野）。 **自适应反馈。**如果 Adam 错过一两天，