上面说了那么多，其实就是量小的时候用 if-else if-else 完全没有问题。
至于字典行不行？当然是行的啊，用字典属于表驱动模式的一种实现，完全是合乎软件工程的要求的。

所有用跨平台的方案的，最后都会回到原生方案。
除非你们公司是 facebook, microsoft。当然了，所谓的 app 里面嵌套浏览器内核国内大厂还是玩得很溜的。
自己开发随便

@zealot0630 的确是，不过你有几千分，你可以 close 啊，分数低就 downvote 罗，没办法。

@zealot0630 你用你问题审查权限，直接申请 close 掉，看到辣鸡问题给个 downvote 没有问题

高级程序员？那么不如去读个 PhD ？

作为一个 SO 的入门用户，这应该不是恶意的，因为你的问题如果是有争议的，被 downvote 了是会有人 upvote 的，我就试过。而且高分用户是有自治权的。比如对问题质量的审查。好像是过了 500 分就有了。
因此问题质量低下是很快就被关闭的。如果能直接得出答案的，建议自己直接操作。

@ysc3839 假如是 3.5 以后的扩展，你可以试试写一个 pyi 文件

dict 是通过 C 语言实现的，据我理解，__built__.py 只是一个 stub 而已

其实是跟编程语言相关的，虽然 celery 说自己也是一个 actor 框架，任务队列。但是相对于 Java，你说 actor 框架，他们有 akka，任务队列也不少。还有就是队列什么他们一个都不少，有真线程，最简单的难道不是开一个线程去干，干完了就同步一下以及回调吗？

@Deardrops 这就是语言的哲学，也是面向对象的进一步理解。面向对象应该基于协议，接口。组合优先于继承，既然满足了接口，那么就应该认为这里的对象就是一类。

@woshichuanqilz 你将断点设置在 elem_name 赋值之后的下一行试试

@SamsonWang 其实这是违法的，劳动法规定不能随便降薪资的。

@reus
我觉得你应该先讨论问题，不要是不是就扣一个非用户的帽子。退一万步哪怕我是一个不经常用的人，我也可以发表观点。相反你一个经常使用的人面对这样一个设计，你一句话没什么影响，大概 Rob 也是这样想的。

@scnace 现在是 2018 年，error handling 跟泛型现在才说要做要改，如果你认为这是积极我也没办法，反正我对比了同期的语言，我认为这就是在这个特性上面不积极。

@wangxiaodong 关键现在 golang 的 package 管理也不见得多去中心化，大部分依赖 github。但是这个方式无法让企业内部快速建立一个代码仓库镜像。

@reus 你说得对啊，现在都 1.11 了，也就上个版本。但是除了这个工具，官方还做了什么？语义化版本号对吧。降低 GOPATH 的影响是吧？

你说这些是重点吗？我上面说了那么多是说这个工具吗？我是喷官方长期不作为，而且没有建立一个中心化的仓库。
你倒是说说这个优势是什么，这个才是让人觉得巨难受的地方

@taowen
@reus
不对就要喷，分散代码，靠 github 管理有什么好？
集中的一个源，我可以说有以下几个优点
1. 快速部署镜像
2. 不会因为 github 的地址变更而改变依赖关系。你们自己想想到底有没有 github repo 转让过用户，转让了是不是不用动代码，一个新的项目参与者能用什么方式同步依赖？

为什么 Rob 就一定要采取这样的方式来管理依赖，你们说这个没有受到 Google 内部的基础设施影响，你们自己信吗？
自从 Golang 发布依赖出现了多少依赖管理工具，为什么官方就不钦定一个？原因就是 Google 内部没有这个必要。bazel 加上单一的版本库，完全就可以解决版本控制，构建的问题。但是一般公司不是这样，这样才是为什么 2018 年了，golang 的版本控制还是如此让人蛋疼。

同时你们觉得时不时插入的 check error 没有影响思路的，我觉得也是可以，毕竟这个风格问题。问题也不大，正如没有泛型也可以自己写一个代码生成器生成代码，或者编辑器编写代码片段。但是你们倒是说说用 github 作为代码仓库有什么好处？

@SuperMild 但是他为什么不做？原因就是 Google 不需要，你们社区要不要，他不管。
Rob 不是圣人，要排资论辈 cpp，Java 哪个不是大牛设计？
错误就是错误，跟谁做的没关系。

历史就是明证，说泛型无用，check error 最好的，官方都在打脸。

我只想说，包管理是很难么？为什么现代化的语言都用中心话管理，golang 就整天扯这些。
承认吧，golang 在依赖管理这方面就是个残废，就是想着自己内部有一个超级大的代码库，什么都可以从里面 checkout。
压根就没有考虑其他人的使用。1991 年发明的 Python 跟 Java 都有很成熟的包管理方案，大家都习惯这样的做法。golang 到今天还要整天发文说这个版本号管理，那个机制管理。简直是败笔，无病呻吟，自找麻烦，抄都不会抄！

为什么难理解，其实是大家看书查资料的方向错了。这里虽然是协程，但更多的是事件驱动编程，除了用上了 await 来解决以前的装饰器，还有一些默认的封装。但本质还是事件驱动编程。具体可以看 linux 网络编程，跟 epoll 相关的内容。现在大多数事件循环在 Linux 下都是封装 epoll，将对应的套接字以及回调函数注册到 epoll 实例上。抓住本质自然就会了解。其实很多现在这些框架的作者是默认你了解这部分内容的。

@passerbytiny
第一我没叫你换
第二我只是回答别人对破解版的质疑
第三我觉得你这样只能从工具上面来获得成就感的人很可怜