RSS Python星球 笔记

RSS Python星球

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

笔记线程

类似 VS Code 的工具难以识别项目的 Python 环境,从而阻碍了代码执行和依赖分析等关键功能。这一挑战的根源在于编辑器缺乏一种通用方法来检测项目所采用的工作流工具,或定位其虚拟环境的位置。当项目首次打开时,VS Code 无法可靠地判断用户是否偏好使用 Hatch、Poetry、uv 还是自定义方案。现有方法通常依赖于根据 pyproject.toml 进行猜测,这需要维护一个精确的支持工具列表。此外,将环境存储在全局位置或允许共享环境的工作流工具会进一步增加识别难度,尤其是在用户管理众多环境的情况下。对于存储在本地 .venv 目录中的环境,存在一种简单解决方案,可提供基础功能。然而,对于位于项目之外或存在多个环境的情况,则需要一个专用文件(如提议的 .python-envs)来列出其路径。为解决工具偏好问题,建议在 pyproject.toml 中引入 [workflow] 表,以定义工具如何以服务器模式启动,从而基于工作流服务器协议(Workflow Server Protocol)通过 JSON-RPC 进行通信。该协议允许工具向编辑器报告可用环境并管理其创建。另一种替代方案是建立 CLI 工具的命名约定,使其返回所需的环境详情。作者的动机源于希望简化所有 Python 用户的设置流程,无论其经验水平如何,通过最小化手动环境管理来实现。本努力旨在提供非 VS Code 专用的解决方案,以便其他编辑器也能采用。此类标准化的通信协议将使工作流工具超越单纯的中间件角色,实现更广泛的编辑器支持,并减少定制扩展的开发工作。
CdXz5zHNQW_ULVmhrrNLw.png
AI 系统会做出不可预测的错误,因此必须对每一个输出进行验证。这一验证过程的成本可能等同于原始任务本身,从而促使成本被外部化至他人身上。一个关键关切是“反向半人马”现象,即雇主将员工转化为无偿的 AI 验证者。这是因为 AI 输出错误构成一种普遍的外部性,使得由人类完全承担该项工作更为廉价。“代码审查是瓶颈”这一论断凸显了对人类理解的必要性,而不仅仅是技术审查。在竞争环境中,AI 通过让“爬梯者”能够快速生成大量代码,同时将验证负担转嫁给他人,从而为其提供助力;这种动态有利于提示者,却可能导致严重问题,而审查者往往成为替罪羊。AI 还擅长充当“吉什加洛普”(Gish Galloper),以大量谬误淹没对手,尤其在政治话语中。欺诈、垃圾信息和诈骗借助 AI 快速生成令人信服的文本的能力得以实施,并将验证成本外部化给受害者。客户支持机器人常被视为对抗性工具,利用 AI 迅速驳回或拖延客户,优先追求指标而非解决问题。在教育领域,AI 使得作弊广泛蔓延,因为学生将验证工作外部化给教师。尽管有人设想 AI 可用于针对强大实体(如保险公司)的正当申诉,但这些实体的结构性优势往往占据上风。即使 AI 的有益用途也可能升级为军备竞赛,进而导致更差的长期结果。AI 的摘要和问答能力同样可被武器化,尽管阅读行为本身被视为对网站内容更具破坏性。
作者观察到一种日益增长的趋势:在编码代理之上构建系统,形成循环,从而将代理的能力延伸至单个会话之外。这些循环涉及任务队列、机器执行以及一个决定器(harness),该决定器通过修改上下文或将任务发送至另一台机器来判定是否继续执行任务。虽然编码代理内部已存在用于任务的循环,但一种新的外部“决定器层级”循环正在兴起并主导着讨论。作者个人对这种放手式的方法感到困扰,尤其对于自己关心的代码,发现生成的代码过于防御性、复杂,且缺乏强有力的不变量。当前模型倾向于添加过多的局部防御,而非防止不良状态,这一问题似乎正在恶化。循环放大了这种倾向,使得系统更难理解,却显得更为稳健。然而,循环在代码移植、性能探索和安全扫描等领域表现出色,在这些场景中,代码转换或短期存在的工件是目标,生成代码的持久性或可验证性不如探索或转换过程关键。作者将编写持久性代码与此对比,将其比作从“软件作为确定性机器”向“软件作为有机体”的演进。这一转变意味着从深度人类理解转向监控、稳定化,并将系统几乎像生物实体一样对待。退出这种由机器驱动的未来正变得愈发困难,尤其是在安全领域,攻击者和研究人员已在使用循环,迫使防御者适应。竞争压力以及部分团队利用编排技术所展现的速度也将推动采用。最令人担忧的是对这类循环系统可能产生的认知与实践依赖,这引发了关于未来访问权限、成本以及在不借助机器辅助的情况下理解代码能力的疑问。最终,代码库可能在维护上依赖于机器的参与。
Rust 平台拥有大量练习,每个练习都需要用户加载编辑器、编写代码,并通过 Rust 后端进行验证。该流程需要端到端测试,以确保更新不会破坏现有功能。手动测试效率低下,且无法覆盖从登录到接收反馈的完整用户流程。虽然 Django 应用和 Rust 验证器已存在单元测试,但它们并未测试练习的集成体验。Playwright 结合 pytest 为此类端到端测试提供了一种简洁的解决方案。单个 Python 测试函数通过从数据库获取所有公开练习及其解决方案进行参数化。每个参数化测试导航至一个练习,将正确解注入编辑器,并验证提交结果。测试断言接收到的反馈表明练习已成功完成。pytest 中的会话作用域 fixture 被用于优化性能,确保浏览器启动和登录操作在所有测试中仅执行一次。Playwright 测试的一个关键方面是处理元素时序,特别是针对 CodeMirror 编辑器,需使用显式等待以确保元素可见且其 JavaScript 实例已初始化。为避免 Django 异步上下文陷阱,在创建测试用户时实现了一个变通方案:使用一个独立的 fixture,该 fixture 在 Playwright fixture 之前运行,并借助 django_db_blocker。端到端测试设计为针对真实数据库和实际的 Rust 验证器运行,从而确保集成测试的真实性。这些测试在主要推送前在本地执行,而 CI 环境主要运行速度更快的单元测试。这种方法可自动测试新添加的练习,无需编写新的测试代码,且任何前端修改都将在此集成回归测试套件中得到验证。相较于 Selenium,Playwright 因其现代化且符合人体工学的界面而更受青睐,而元素时序问题则是一个可管理的挑战。
为了区分 Python 中的方法类型,请观察该方法所使用的参数。如果它需要实例(通常由 self 表示),则它是一个实例方法,用于修改对象状态。如果它需要类本身(cls)但不需要特定实例,则它是一个类方法(classmethod),适用于替代构造函数或注册表等场景。当方法既不需要 self 也不需要 cls 时,它是一个静态方法(staticmethod),可视为一个独立的辅助函数或工具函数。类方法在多种构造方式创建对象时尤为有用,因为 Python 不允许重载 __init__。例如,从时间戳或 ISO 字符串创建日期,正如 datetime.date 中所见。这些方法使用 cls 以确保正确创建子类的实例。类方法的另一个常见用途是管理类级别的状态,例如插件注册表或计数器。静态方法本质上是一个封装在类中的独立函数,主要用于组织目的。它适用于与类职责紧密耦合的辅助函数,例如 Color 类中的转换工具。然而,如果某个静态方法在逻辑上并不属于该类,那么将其作为模块级函数可能更合适,以便于测试。核心原则是确保方法执行的工作与其指定范围相关。随着 AI 生成代码日益普及,对其结构和目的进行批判性评估至关重要。一个仅仅将参数转发给 __init__ 而未增加任何价值的类方法,可能表明对概念理解不足。同样,一个本可以是独立函数的静态方法,其结构可能并不恰当。无论代码来源如何,在审查代码时建立扎实的 Python 最佳实践意识都至关重要。这一决策规则为此类评估提供了一个简单的框架。
Pluggy 是一个用于在工具和库中构建插件系统的 Python 库。它最初是为 pytest 项目开发的,随后被提取为独立的库。Pluggy 的核心概念围绕钩子(hooks)展开,这些钩子由宿主应用程序暴露,并由插件实现。宿主使用 HookspecMarker 定义钩子,而插件则使用 HookimplMarker 实现它们。该库还用于创建一个名为 htmlize 的示例工具,该工具可将标记转换为 HTML,并通过插件支持自定义角色和内容处理。宿主定义特定的钩子(如 htmlize_role_handlerhtmlize_contents),以便插件扩展其功能。这些钩子可接受多种参数,并返回用于处理数据的函数。Pluggy 的 PluginManager 负责加载插件,并提供一种便捷的机制来发现注册为 setuptools 入口点(entry points)的插件。这使得通过 pip 安装的插件能够被宿主应用程序自动发现和加载。宿主也可以使用自定义的插件发现方法,直接将插件注册到管理器中。调用已加载的插件十分简单;PluginManager 协调对已注册钩子实现的调用。钩子调用通常返回所有已附加插件的结果列表,并提供选项以控制执行顺序。插件通过用宿主的 hookimpl 标记装饰其函数来实现钩子。Pluggy 与基本的插件概念(如发现、注册和钩子的使用)高度契合。它提供了一种符合 Python 风格的方式,将宿主 API 暴露给插件,并利用标准的 Python 导入机制。虽然构建插件系统可能很简单,但 Pluggy 提供了高级功能,如签名验证、一致的结果收集以及排序选项。是否使用 Pluggy 取决于项目需求,需权衡其高级功能的优势与引入依赖的代价。该库自动注册入口点的机制对于使用标准 Python 打包工具的项目尤为有用。总体而言,Pluggy 为构建可扩展的 Python 应用程序提供了一种强大且灵活的解决方案。
Twitter 用户正以幽默的方式看待 Anthropic 在出口管制方面面临的困境,因为该公司此前对人工智能风险的强调如今似乎直接波及自身。美国政府指示暂停向外国公民提供某些人工智能模型的访问权限,凸显了日益加剧的分裂:强大技术正依据国籍受到限制。这一发展表明全球正走向碎片化,人工智能被视为武器而非推动普遍进步的工具。美国出口管制政策,特别是针对其境内外国公民的措施,标志着管控方式从政府主导转向以个人国籍为依据。这种排他性做法引发了担忧,即民族主义可能凌驾于真正的安全考量之上。欧洲国家被敦促认识到这一转变,因为其自身的技术政策难以应对一个由权力而非监管定义的地缘格局。欧洲对美国技术平台和供应链的依赖,使其在人工智能相关的地缘政治讨论中处于脆弱地位。作者批评欧洲内部的碎片化及官僚障碍,这些障碍抑制创新并将雄心勃勃的创始人推向美国,从而形成人才流失与生态系统薄弱自我强化的循环。文章主张欧洲必须培养更大的雄心、更强的自主意识以及建设意愿,超越单纯的监管。作者警告不要简单模仿美国,既承认其优势,也指出其社会分裂及好战倾向。作者强调国际合作与开源原则的重要性,作为应对人工智能权力集中于少数人之手的对策。最终,该文倡导合作,警示一个由竞争权力集团主导的碎片化世界将侵蚀个人权利与稳定。
CdXz5zHNQW_4pUpCNfA9x.png
作者热情地重新加入了主权科技 fellowship,此前已参与了其成功的 2025 试点项目。该 fellowship 为关键开源技术的维护者提供至关重要的资金支持。作者的参与使其能够专注于发布 Python 3.14 和 3.15 版本,同时开展导师指导与社区支持工作。一份全面的评估报告详细阐述了该项目的益处,包括作者的具体成就。Python 3.14.0 的顺利发布显著得益于 fellowship 所提供的专属时间,使作者能够主动解决问题,并从容应对加速发布。作者有效指导了新的发布经理和 triager,通过社区参与和信息公开分享,促进了透明度。通过自动化改进和网站可访问性提升,对数千万用户产生了影响。开发了一个 triage 仪表板,用于管理大量问题并回退关键安全修复,展现了显著的组织影响力。作者还倡导非技术性改进,成功提议在 PyCon US 和 EuroPython 之间交替举办语言峰会,以促进更大的多样性。这一组织工作涉及核心团队内经过充分讨论和提案的流程。额外分配的自由时间既用于个人兴趣,也用于支持本地 Python 社区,促成了 meetups 的共同组织。fellowship 通过月度会议和线下活动,促成了宝贵的联系与知识共享。作者的广泛贡献包括大量 GitHub 提交、版本发布、会议演讲以及社区组织工作。展望未来,作者对扩展后的 2026 年 fellowship cohort 充满期待,该 cohort 将包括社区经理和技术作家。主权科技机构(Sovereign Tech Agency)的持续工作对于改善开源基础设施至关重要,并影响着新的欧盟倡议,如欧盟主权科技基金(EU Sovereign Tech Fund)。
CdXz5zHNQW_dXsJvecBsg.png
CdXz5zHNQW_AAH5sMMiqO.jpeg
我一直长期坚定支持开源,并曾尝试为其提供资金支持。我深信开源理念最终必将获胜,但这一胜利并非自动实现,也非一蹴而就。当前,开源正面临人工智能垃圾内容(AI slop)、贡献者格局转变、代码生产成本下降以及大型公司学会关上大门等多重压力。当今这场斗争的核心之一在于叙事操纵。社交媒体和商业圈的意见领袖日益将“访问权”框架为“不负责任”。正因如此,欧盟《数字市场法案》(DMA)才具有重要意义,尽管许多人(包括我自己)本能地反感欧盟监管。苹果在欧洲推迟人工智能功能的争议,并非仅仅因为布鲁塞尔令人恼火:关键在于用户是否能够访问自己的设备和数据。手机属于你,数据也属于你,但苹果却决定谁能触及它们,剥夺了你的自主权,随后又试图将此举描绘成符合你的利益(声称是为了你的安全与保障)。越接近人工智能的核心,这一问题就越凸显。Anthropic 有充分的经济动机限制人们对其 Mythos 和 Fable 模型的使用,并将这些限制包装在安全与(国家)安全的话语之下。部分限制或许可以辩护,但并非全部如此。这些模型是在公共作品基础上训练的,却阻止开源社区对其进行学习与提炼。对欧盟、中国或其他任何大型政府持批评态度,不应让我们忘记:真正的技术民主化访问,包括人工智能,符合我们所有人的利益。某些暂时的产品痛点,包括苹果人工智能功能的延迟,若有助于保持门户开放,则值得付出代价。我们不应让公司垄断“限制访问符合我们利益”的叙事,尤其是对于欧洲而言,我们的资本市场尚不发达、人才外流以及内部纷争,已使局势对我们不利。