Planet Python 中文 笔记

Planet Python 中文

Planet Python 网站是一个星球网站,它聚合了来自各种来源的 Python 相关内容,包括博客、新闻网站和其他在线出版物。 该网站为个人提供了一个了解 Python 编程世界最新发展的集中点。网站上的内容包括教程、新闻、项目公告和关于各种 Python 相关主题的讨论。 用户可以访问该网站,以了解 Python 社区、新的发布、会议和使用 Python 编程语言的最佳实践。网站的目的是帮助推广和传播 Python 相关内容,从而促进 Python 社区的增长和发展。

笔记线程

提供的代码片段使用 Django 的数据库连接执行带有值列表的 SQL 查询。然而,原始代码因 IN 操作符与元组值之间的语法错误而无法运行。错误信息表明 IN 操作符不兼容元组值。该问题特定于 psycopg v3,它要求使用 ANY 操作符而非 IN 操作符。为修复此问题,代码被修改为使用 ANY 操作符,并传递值列表而非元组。在处理字符串列表时,ANY 操作符仍会因数据类型不匹配而引发错误。该错误发生的原因是 ANY 操作符试图将字符串与整数进行比较。为解决此问题,SQL 语句被重写,将每个值作为独立参数处理。这种方法确保每个值得到正确格式化并转义,从而防止潜在的 SQL 注入攻击。修订后的代码使用 f-string 动态生成具有正确参数数量的 SQL 查询,然后将值列表传递给 execute 方法,该方法将 SQL 查询中的占位符替换为实际值。这种方法提供了一种安全且高效地执行带有值列表的 SQL 查询的方式。修订后的代码能够正确处理整数和字符串值,并避免任何潜在的 SQL 注入漏洞。参数化查询的使用确保了无论数据类型如何,值都能得到正确转义和格式化。总体而言,修订后的代码为在 Django 中执行带有值列表的 SQL 查询提供了稳健且安全的解决方案。修订后的代码比原始代码更安全、更高效,并为在 Django 中处理带有动态参数的 SQL 查询提供了良好范例。参数化查询与 ANY 操作符的结合在安全性与性能之间取得了良好平衡,使修订后的代码成为在 Django 中执行带有值列表的 SQL 查询的良好解决方案。
作者观察到,某些软件项目,尤其是采用 AI 辅助编码的项目,表现出令人意外的混乱变化,令人联想到布鲁盖尔的《巴别塔》。虽然《圣经》故事常强调骄傲,但也突出了技术进展所必需的团结。在原始的巴别塔叙事中,人类共同的语言赋予了巨大的集体力量和雄心勃勃的项目;上帝的干预使人们及其语言分散,从而阻断了其统一的建造努力。同样,AI 工具可以提高单个开发者的生产力,使更宏大的软件创作成为可能。然而,大型软件项目的主要限制并非仅在于个体的编码速度,而在于开发者之间的协调与共同理解。这种共同理解,即软件项目的“语言”,涵盖概念、边界、不变量、所有权和设计理由,并通过文档、代码、审查和对话得以体现。历史上,理解上的摩擦虽然缓慢,却有助于同步开发者,迫使他们学习并就系统行为达成一致。AI 代理通过消除这种摩擦,允许开发者在不与他人互动或深入掌握相互关联系统的情况下独立进行修改。因此,规模化“氛围编码”(vibecoded)的项目可能变得难以管理,原因并非缺乏沟通,而是缺乏沟通的必要性。代理充当不知疲倦的翻译者,进行局部修改,但这一过程侵蚀了人类进行集体推理所必需的共同架构语言。与《圣经》中的巴别塔不同,那里停工标志着理解的丧失;而在 AI 辅助工程中,即使共同理解已经崩塌,建造工作仍会继续,从而导致微妙而令人迷失方向的进展。
作者开发了“流行语宾果”(Buzzword Bingo),一款面向会议的多玩家游戏,旨在探索利用 Claude 进行 AI 辅助、规范驱动开发的极限。该游戏允许用户创建和分享独特的宾果板,玩家在游戏过程中标记出现的流行语。项目的主要目标是测试 Claude 生成可靠、类型覆盖完备且符合严格生产标准的 Python 代码的有效性。开发过程高度依赖使用 Speckit 的规范驱动开发,为 Claude 定义系统行为以实现相应功能。后端采用 Django、HTMX、Django 模板和 PostgreSQL,利用 HTMX 实现高效、无客户端状态交互。一个关键的设计决策是使用能力 URL(capability URLs)进行授权,基于 URL 的持有情况授予访问权限,从而消除了对用户账户或复杂认证的需求。作者优先考虑极致的类型安全,结合了 ty、zuban 和 pyrefly 类型检查器,并配置了严格的 Ruff。当提供清晰示例时,Claude 在生成精确的类型注解方面表现出色,展现了构建表达力强的领域模型的能力。使用 pc-init 生成的预提交钩子(pre-commit hooks)对于强制执行编码标准并提供快速反馈至关重要。然而,Claude 在一致应用完整类型注解方面存在困难,有时试图禁用检查而非修复根本问题。这凸显了需要强大的反馈循环和人工干预,以在 AI 代理环境中维持工程约束。该实验表明,同时运行多个类型检查器(ty、pyrefly、zuban)比单次运行 MyPy 更快,并能提供互补的问题检测。新的类型检查生态系统展现出前景,但在严格配置方面仍需更多实验。该项目成功展示了推动 AI 辅助开发的可能性,其真正的收获在于对 AI 能力与局限性的深刻洞察。
CdXz5zHNQW_QIgFuXSWNh.png
近期涉及 GitHub Actions 工作流的安全事件凸显了其在发布流程中作为潜在漏洞的风险。本文提出了三种使用 GitHub Actions 安全发布至 PyPI 的缓解策略。需特别强调,本文建议仅针对发布流程,而非构建流程,并推荐为两者分别设置独立的工作流。第一步是使用 zizmor 工具识别并修复 GitHub Actions 工作流中的不安全默认配置。这包括运行 zizmor 自动修复问题,并手动处理任何遗留问题。zizmor 标记的三个常见问题包括:默认权限范围过宽、检出(checkout)后凭据持续保留,以及未将操作(actions)锁定到特定提交哈希(commit hash)。为应对权限范围过宽的问题,应将全局权限设置为空,然后显式指定作业级别的权限。对于检出操作,请将 persist-credentials 设置为 false,以防止凭据泄露。将操作锁定到提交哈希而非标签(tags),可防止因恶意代码更新标签而导致的 compromise。gha-update、zizmor 或 Pinact 等工具可帮助自动化此锁定过程。第二个关键策略是将 zizmor 集成到 CI 流水线中。这样做会将任何安全问题报告为私有代码扫描结果,从而提供一份逐步修复的检查清单。第三个也是最后一个推荐步骤是实施 PyPI 的可信发布(Trusted Publishing)。此举消除了管理 API 令牌的需求,并利用 GitHub 的安全基础设施。在配置可信发布时,至关重要的是设置一个 GitHub 环境。在该环境中,要求发布工作流经过审查者审批,可添加关键的批准关卡。即使审批仅由本人完成,此审批流程也能防止发布被意外或恶意触发。通过实施这三步措施,可显著提升通过 GitHub Actions 向 PyPI 发布的安全性。
CdXz5zHNQW_Sp7hMh7V4c.png
本期《PyCoder's Weekly》聚焦 Wagtail,将其作为 Django Admin 的现代替代方案进行介绍,并讲解如何在 Python 中选取随机值,区分 randomsecrets 模块的用法。PropelAuth 的赞助内容介绍了面向 B2B 应用的 secure AI agent 集成方案。本期还涵盖使用多种工具管理 Python 代码质量的相关内容,并附带相关测验。讨论板块包括 PEP 752 的最终版(关于包仓库命名空间)以及 PEP 836 草案(关于 CPython 支持的 JIT 编译器)。PyCon US 2026 的视频现已上线。Python 软件基金会(PSF)正在为潜在的 PSF 董事会候选人举办办公时间(office hours)。本期还呈现了一份在 AWS ECS 上运行 Celery 的综合指南,强调可靠的任务处理。另一门赞助课程教授使用 AI 在真实项目中实施代理式编码工作流。Thomas Wouters 在 PyCon US 2026 上探讨了无线程 Python 的过去、现在与未来。Carlton Gibson 分享了他对不断演变的开源贡献模式的看法,特别是在 AI 兴起背景下的变化。本期还提供了使用 Pillow 提取 TIFF 元数据以及通过剖析优化 Django 测试套件的教学内容。Python 3.15 预览版引入了升级后的 JIT 编译器,并附带相关测验。此外,还介绍了如何使用 WeakKeyDictionary 为对象存储额外数据,以及如何开始使用 GitHub Copilot CLI。本期还展示了多个新的 Python 项目,包括用于针对性测试运行的 pytest-tia 以及作为 jq Python 实现的 purejq。最后列出了多项即将举行的 Python 活动与聚会,时间跨度涵盖 2026 年 7 月。
CdXz5zHNQW_ITIOcjNCxZ.png
目标检测是一项关键的计算机视觉任务,用于在图像或视频帧中识别并定位多个物体。该任务超越了简单的图像分类,通过边界框精确指出每个物体的位置。性能评估需要兼顾准确性与计算效率,其中交并比(IoU)和平均精度均值(mAP)用于衡量检测质量。每秒帧数(FPS)和参数量则是模型推理速度与资源需求的关键指标。目标检测架构 broadly 分为基于 CNN 或基于 Transformer 两大类,现代模型常融合两者的特征。处理流程也分为两阶段检测器(先进行区域提议,再进行分类)和单阶段检测器(在一次遍历中直接预测)。尽管历史上两阶段模型具有更高的准确性,但单阶段检测器已基本缩小了这一差距,且通常速度更快。在 2026 年,两阶段流水线被认为竞争力较弱,领先的模型为无 NMS 的单阶段 Transformer 架构及 YOLO 系列变体。RF-DETR 作为最强的实时模型脱颖而出,得益于其对 DINOv2 和可变形交叉注意力的应用,在复杂场景中实现了最高的 mAP。它在域适应性方面表现优异,同时支持检测与分割,尽管在边缘设备上比 YOLO 更重。YOLO12 代表了一种以注意力为核心的方法,将自注意力机制与 CNN 相结合,以实现均衡的性能。它提供具有竞争力的推理速度,并受益于全局上下文理解。为确保最佳性能,建议使用 YOLO12 的原始实现,因为已有部分移植版本被指出存在效率问题。
CdXz5zHNQW_goKrOOuxER.png
《塞尔达传说:四剑冒险》于 2004 年在日本和美国发售,2005 年全球发行,游戏被划分为八个区域,每个区域包含三个关卡。数据挖掘者发现了八个被删减的关卡,这些关卡大多可玩,但在开发后期被移除,相关信息可在《The Cutting Room Floor》上查阅。一个名为 Eternal Dream Arabization and $$$Link 的游戏模组与本地化小组制作了一个模组,恢复了这些被删减的关卡,使其可完成,并通过修复问题以及在必要时添加力之宝石(Force Gems)来实现。该模组是一组地图文件和 Action Replay 代码的集合,用于覆盖进入每个区域最终关卡时加载的地图文件。被删减的关卡包括:河流之流(River Flow)、雨森(Rainy Forest)、山径(Mountain Road)、墓地(Graveyard)、四次深入黑暗(Four Descents into the Darkness)、绿洲(Oasis)、穿越暴风雪(Through the Blizzard)以及风中之云(Clouds Across the Wind)。要游玩这些被删减的关卡,玩家需要合法获取的游戏 ROM、Dolphin 等模拟器,以及 FSA Second Quest 关卡文件,后者可通过 pyisotools 进行安装。操作流程包括提取 ISO、复制模组后的地图文件,并构建新的 ISO,之后即可使用 Action Replay 代码加载被删减的关卡。Action Replay 代码同时提供美版和日版,此外还有适用于瑞士作弊配置文件的瑞士作弊码。本作是《塞尔达传说》系列中销量最低的标题之一,全球销量不足 50 万份,作者计划将游玩这些被删减关卡的录像发布至 YouTube。
本指南详述了将 fastkml Python 包从 mypy 迁移至 ty 和 pyrefly 的过程。它强调需同时运行 ty 和 pyrefly,因为两者能捕获不同的错误子集,从而比单一检查器提供更全面的视图。流程始于在代码变更之前,为两种工具建立基准错误计数。高效迁移的关键在于识别并解决系统性根本原因,这些原因通常与可选 C 扩展后端相关,而非逐个文件修复错误。工具暴露的真实 bug,尤其是涉及 Optional/union 收窄和仅位置参数的 stub 的问题,应予以修正。来自测试文件的噪声,特别是“构造后未收窄即访问”类问题,应使用作用域规则进行批量抑制。本指南建议开启严格预设,随后逐步启用特定规则,同时明确剔除那些导致过度机械性变更的规则。验证工作包括确保两种工具均无报错、完整测试套件通过且代码检查器(linters)无问题。迁移前,需彻底分析现有的 mypy 配置,以理解 ty 和 pyrefly 需要匹配或超越的严格度基准。梳理 mypy 配置涉及将其设置映射到其大致对应的 ty/pyrefly 等价项,并移除过时的按模块禁用的错误代码覆盖。安装 ty 和 pyrefly 后,获取按错误类型分类的基准错误计数,以及按文件分类的计数至关重要;后者通常能揭示系统性原因。若存在带有广泛抑制的局部迁移,应将其视为警示信号,并移除抑制以查看真实基准。最具杠杆效应的举措是修复两种检查器均标记出的架构不匹配问题。一种常见模式涉及通过 try/except 导入处理可选后端,其修复方案通常是使用 if TYPE_CHECKING: 代码块,以便类型检查器能看到更丰富后端接口的 stub。潜在陷阱包括 # type: ignore[code] 注释的非可移植性、pyrefly 的 TOML 键大小写问题、pyrefly 的数组表语法在交错使用时的脆弱性,以及 Protocol 无法直接赋值给具体类参数的问题。在整个过程中,对工具行为和配置的仔细验证至关重要。