为什么functools.partial默认不继承__name__等元数据？

partial默认不复制原函数的__name__、__doc__等元数据，不是设计疏漏，是刻意选择的行为，核心是规避默认继承带来的逻辑混淆和实际bug，常见的问题场景包括这几类：

• 可调用对象的身份识别会被干扰
  partial的返回值本质是独立的functools.partial类型实例，不是原函数的“别名”或者修改版，它的调用逻辑、参数签名和原函数已经有明确区别。如果默认继承原函数元数据，调试、打日志、看调用栈的时候，你看到一个名称、文档都和原函数完全一致的可调用对象，根本第一时间反应不过来它是预填了部分参数的包装对象，很容易出现“明明函数签名要求传3个参数，我传3个怎么报参数数量错误”这类无意义的排查成本。
  举个最常见的场景：你基于原始的send_request函数，分别生成了预填GET参数、POST参数、超时时间的3个partial实例，如果三个对象的__name__全是send_request，日志里的调用记录、错误栈根本区分不了实际调用的是哪个包装对象，线上排障效率会极低。
• 不存在普适的元数据继承规则，硬加默认逻辑会破坏现有业务逻辑
  函数元数据远不止__name__和__doc__，还包括__module__、__qualname__、__annotations__、函数签名、自定义属性等各类信息，不同场景下对元数据的需求完全相反：
  做普通装饰器的时候你可能需要完整复制原函数元数据，但做插件注册、路由自动收集的时候，你往往需要根据可调用对象的__module__判断归属，如果partial默认继承原函数的__module__，你在当前业务模块生成的partial实例会被错误归类到原函数所在的工具模块，直接导致注册逻辑失效。
  类型检查、参数校验场景下问题更明显：partial已经预填了部分参数，签名和原函数完全不同，如果默认继承原函数的__annotations__和签名信息，类型工具会误判参数缺失、参数多余，给出完全错误的提示。
• 符合Python“显式优于隐式”的设计原则
  默认不继承元数据的行为是完全无副作用的：需要复制元数据的场景，你可以用update_wrapper手动指定要复制的属性、要排除的属性，行为完全可控。如果反过来默认复制所有元数据，遇到元数据干扰逻辑的场景，你需要手动逐个清理错误的属性，不仅麻烦，还很容易漏删属性引出隐蔽的线上bug。

早期Python社区确实提过让partial默认继承元数据的提案，测试时就触发过实际故障：有Web框架的路由自动注册逻辑会收集模块内所有可调用对象，用__name__作为路由键，默认继承元数据后，同一个原函数生成的多个不同partial实例路由键完全重复，注册时互相覆盖，导致大量路由失效。

内容的提问来源于stack exchange，提问作者BenedictWilkins