singledispatch：按参数类型分派函数

做的事：真实注册几个类型的handler，故意不给子类单独注册

代码@singledispatch def process(arg): return f"default handler: {arg!r}" @process.register def _(arg: int): return f"int handler: {arg}" @process.register def _(arg: list): return f"list handler: {arg}" class Animal: pass class Dog(Animal): pass # Dog从没单独注册过 @process.register def _(arg: Animal): return f"Animal handler: {type(arg).__name__}" print(process(Dog())) # 会走哪个handler？

验证：Dog真实命中了Animal的handler，singledispatch沿MRO查找

process(5)          → int handler: 5
process([1,2,3])    → list handler: [1, 2, 3]
process("hello")     → default handler: 'hello'    ← str没注册过，走默认
process(Dog())        → Animal handler: Dog          ← 真实命中了Animal的handler！

process.registry.keys() → dict_keys([<class 'object'>, <class 'int'>, <class 'list'>, <class '__main__.Animal'>])
← 真实registry里完全没有Dog这个类型的独立条目

验证：这套灵活的类型查找真实不是零成本的

singledispatch call: 0.1229 s for 500000 calls
plain function call: 0.0369 s for 500000 calls
真实倍数: 约3.3倍

真实测出的这个差距，跟前一节验证的MRO查找机制直接对应：普通函数调用真实只是一次固定的函数指针跳转，singledispatch每次调用真实都要先看第一个参数的类型，再真实沿着它的MRO链条查找registry（内部有缓存优化重复查找同一类型的开销，但本文这次每次都是process(5)同一种类型，缓存命中之后依然比直接调用慢），这份类型分派的判断逻辑真实是有代价的。这跟本系列前面讲的很多"更灵活但更贵"的机制是同一类真实取舍：singledispatch提供的价值是可以用比一大串isinstance判断更清晰的方式组织"根据类型分派逻辑"这件事，还能真实借助MRO自动覆盖子类，代价是每次调用真实比一次朴素的直接函数调用慢上几倍——对于调用频率不是极端高的场景（比如序列化、格式化这类偏应用层的逻辑），这份代价通常真实换来的可读性和可扩展性是值得的，但如果这个函数真实在每秒百万次调用的热路径上，这份开销值得留意。

分步演示：从子类自动命中父类handler到量出来的真实开销

每一步都是本文上面用真实的functools.singledispatch跑出来的原始结果。