@hflyf123 还好吧，这个看不出有什么问题吧。不过我想了个新的，晚点更新一下

@virusdefender 不会呀，我这边测试都是没有问题的，你的浏览器是什么？

这个域名都是在一个人（霍改珍）手上的，他似乎是早期的域名投资人，投了一堆稀有域名.cn 什么的，不过那是零几年，这种域名还是不是很贵的。不过这个头像应该只是网络头像，是谁估计就找不到了。

@deepreader singledispatch 的初衷是提供一种 Python 的函数重载机制的实现，我这个也差不多。如果你条件判断比较复杂的话，是不推荐是用隐式的判断设计的，那才是真的雪上加霜，尽管是可以实现的。

@TJT https://docs.python.org/3.6/whatsnew/3.6.html#new-dict-implementation Python3.5+之后已经大幅度优化了 dict 的存储模型，基本的模式以及对应的算法以及算是最优的了。然后我前言里就说了，逻辑链少的时候用 if elif 完全没问题。

@luguhu key 这个参数是标注着 func 中需要识别参数的位置或名称的，判断条件是任何可 hash 的，注释还是都写清楚了的

在这里总结一下，我博客里的内容也更新了，在文章最上面也有地址：

对比两种处理方案，区别在于显式*dict*的存在。对于显式的 dict 存在，方便索引和查看具体 case 和对应的处理函数，而对于 case 的增加或者删除，都得增加或删除对应主入口中 case 和 func 的键值对。而装饰器的存在简化了上述步骤，而对应的代价则是将 dict 的存在隐式化了，类似的设计模式同 Web 框架中路由注册。

1. specificdispatch 只是一个单纯的 functool，import 了就能用的那种，从行数上来说，使用装饰器和字典来说基本是没有差别的。
2. 从性能角度来说，查表的方法（字典和装饰器）的性能都是是比 `if` `elif` 要高的，是 O(1)的性能。
3. 字典和装饰器的方法，唯一的区别也是在字典是否显式存在，以及是否需要手动维护。

@monkeylyf 的确，在有显式的 dict 的存在时，在各个处理函数被割裂的情况下，也能很方便索引以及查看其对应的 case 的函数。

我提到的多余步骤只是说在编写完一个新的 case func 时，要返回主函数添加对应的 case 和 func 的键值对，反之亦然。简化了这一步骤自然就得显式的 dict 隐式化了，有舍有得的嘛，这就和 Web 框架中，路由注册一样的逻辑。

综上，毕竟我们这也是讨论设计模式而已，所以呢，肯定各有优缺点嘛。

@monkeylyf 直接自己维护 dict 的话，会有多余步骤：

1: 编写对应的 case 处理函数 handle_case_new
2: 将 handle_case_new 函数加到主 handle_case 函数中的 dict 中

我使用装饰器，也就是把这两部合在一个区域而言，对于维护者和扩展而言，是更为方便的。而装饰器是 Python 中非常实用且优雅的特性之一。

@codechaser 额，你没看例子吗？第一个装饰器就是默认情况，之后的 register 才是其他 case。

@virusdefender 我在前言里也说了，条件很少的时候，以及每个条件对应的逻辑不复杂的时候 If else 的很简单明了的。
但一旦条件很多，而且内部逻辑比较多的情况下，使用查表的方式会显得清晰明了。

其次，我是根据 PEP-443 做了一个扩展而言，PEP 不 Pythonic 吗？