廖老师写的是前置检验，也就是url参数还没有传进来就先对路由函数的参数表做一次全面检查，而且has_request_arg只会检查开发者定义的函数参数表，并不会检查url的参数，和客服端url传参一毛钱关系都没有，更多的是检查开发者写的路由函数是否符合要求，然而这个检查并没有什么用，比如上面的例子*request是不能通过字典解压的方式传参数，**request会把参数变成一个字典，这都是本应该捕捉到的错误然而并没有报错，所以说这个前置检查的设计是有问题有漏洞的。

所以我前面说

*request **request

作为参数是会报错的。

廖老师的函数在request的检查上是完备且必要的。

你真的确认是完备的？那么报错信息是什么？这个函数唯一是报错信息就是 request parameter must be the last named parameter in function: ... 用*request作为参数的时候有显示这条信息吗？还是用**request作为参数才显示这条信息？不好意思，都没有显示，那何来的完备呢？那两个例子是我说应该报错而没有报错的例子。没错，*request在传参之后会报错，但和这函数没有任何关系，那是系统自检的报错。那**request传参之后会报错吗？不会！如果你不在路由函数内部使用它，那也是绝对不会报错的！用了，还要看你会不会用，会用则不报错，不会用就报错，但这些已经和has_request_arg无关了。有图为证，报不报错一目了然。

。。。 本来这个就是要配合url一起传参才有意义啊。 不是所有的报错都要集中在一个函数里。 我一直说的是这个是和整个框架一起的约定。 单独拿出来

has_request_arg

讨论没有太大意义啊，就好比说代码层面，整数参数类型不能传字符串，但是在业务层，这个整数限定在1-10这个范围。

你自己也说了，

1.

*request

会报错。

2.

**reques

如果你不在路由函数内部使用它是不会报错，那你这么写函数参数有什么意义呢。

呵呵呵呵... 那has_request_arg这个函数的存在意义是什么？为什么不用一句if 'request' in required_args就搞定了，还要大费周章检查参数的类型，而且还没有报某些应该出错的参数类型报错，报错还要靠系统自检，那这个预先检查的作用何在？

1. *request是会报错，但那是解释器自检的报错，说明有没有has_request_arg都无所谓。
2. **request不用不报错，但我要用呢？按照平常用法肯定会报错，而且这样的报错很难查错，它没明确告诉你是参数定义出错，它只会告诉你request没这个属性。如果是无文档兼且多人编写路由函数时，这样会造成极大的混乱。可见has_request_arg根本就没有起到规范参数表的功能，应该添加报错或直接废弃。

下面看例子好了，当foo(request)的时候，request的方法和属性都是通过request.xxx来使用的，当变成foo(**request)的时候，你已经不能像以前那样通过request.xxx来使用了，它也不会告诉是request参数是定义错了，只会说字典没有xxx的属性，终于你发现可以通过request['request'].xxx可以达到同样的目的，但是，这里已经没有规范这回事了。如果是几个人同时协作写路由，有的人用requesr.xxx，有的人requests['request'].xxx也能调用，但最后merge的人一定头痛死。写句报错代码只不过是两句代码的事，最终弄得代码没有规范如此混乱，你也好意思说是完备的？检查是必要的，但has_request_arg并不是完备了。廖老师也是人，代码不够健壮也是可以理解的，谁也不能保证自己写的框架是完全无bug的，只是有没有被人发现而已。

上面说的这种显示的报错，那还算是比较好的情况，最怕是遇这种隐式的，不会主动报错，但却永不会达到你想要的结果。

哦，你是对的。

哦