Requests项目中的pytest.warns(None)兼容性问题解析
在Requests项目的测试代码中,存在一个与pytest警告捕获相关的兼容性问题。这个问题源于pytest 8.0版本对警告捕获机制的变更,特别是对pytest.warns(None)用法的废弃。
问题背景
Requests项目的测试套件中有一处使用了pytest.warns(None)的代码,其本意可能是想验证某个操作不会产生任何警告。然而,这种用法实际上并不符合pytest的设计意图。
在pytest 8.0之前,pytest.warns(None)的行为被设计为检查代码是否至少产生一个任意类型的警告,这与pytest.warns()或pytest.warns(Warning)的效果相同。这种设计实际上与开发者直觉相反,因为很多人误以为它可以用来验证"没有警告产生"的情况。
技术细节分析
pytest 8.0版本明确废弃了pytest.warns(None)的用法,并会在使用时抛出TypeError异常:"exceptions must be derived from Warning, not <class 'NoneType'>"。这是pytest团队为了消除API歧义而做出的改进。
在Requests的测试代码中,这个用法出现在验证HTTP连接池行为的测试用例中。原始代码试图捕获urllib3库可能产生的警告,但随着依赖库版本的更新和pytest本身的变更,这种写法已经不再适用。
解决方案
最简单的修复方法是直接移除pytest.warns(None)的用法。根据测试验证,在pytest 8.1.1和urllib3 2.0以下版本的环境中,这种修改能够解决问题。
对于确实需要验证"没有警告产生"的场景,正确的做法是使用pytest的警告捕获机制配合断言来检查警告列表是否为空。不过在当前Requests的测试上下文中,直接移除该检查可能是更合适的选择,因为其原始意图可能并非严格验证无警告产生。
最佳实践建议
- 避免使用
pytest.warns(None),因为它已被废弃且行为不符合直觉 - 如果需要验证特定警告,明确指定警告类型
- 对于"无警告"验证,考虑使用pytest的警告过滤器或显式检查警告列表
- 保持测试依赖项的版本更新,及时处理废弃API的迁移
这个案例提醒我们,测试代码也需要像生产代码一样保持更新,特别是当依赖的测试框架发生重大变更时,需要及时调整测试策略和实现方式。
kernelopenEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。C051
MiniMax-M2.1从多语言软件开发自动化到复杂多步骤办公流程执行,MiniMax-M2.1 助力开发者构建下一代自主应用——全程保持完全透明、可控且易于获取。Python00
kylin-wayland-compositorkylin-wayland-compositor或kylin-wlcom(以下简称kywc)是一个基于wlroots编写的wayland合成器。 目前积极开发中,并作为默认显示服务器随openKylin系统发布。 该项目使用开源协议GPL-1.0-or-later,项目中来源于其他开源项目的文件或代码片段遵守原开源协议要求。C01
PaddleOCR-VLPaddleOCR-VL 是一款顶尖且资源高效的文档解析专用模型。其核心组件为 PaddleOCR-VL-0.9B,这是一款精简却功能强大的视觉语言模型(VLM)。该模型融合了 NaViT 风格的动态分辨率视觉编码器与 ERNIE-4.5-0.3B 语言模型,可实现精准的元素识别。Python00
GLM-4.7GLM-4.7上线并开源。新版本面向Coding场景强化了编码能力、长程任务规划与工具协同,并在多项主流公开基准测试中取得开源模型中的领先表现。 目前,GLM-4.7已通过BigModel.cn提供API,并在z.ai全栈开发模式中上线Skills模块,支持多模态任务的统一规划与协作。Jinja00
agent-studioopenJiuwen agent-studio提供零码、低码可视化开发和工作流编排,模型、知识库、插件等各资源管理能力TSX0127
Spark-Formalizer-X1-7BSpark-Formalizer 是由科大讯飞团队开发的专用大型语言模型,专注于数学自动形式化任务。该模型擅长将自然语言数学问题转化为精确的 Lean4 形式化语句,在形式化语句生成方面达到了业界领先水平。Python00