Python 北京开发者活动第一期结束了，虽然我没有参加，不过仍然第一时间拿到了主题的幻灯片分享给大家。和高大上的 Pycon 相比，这种技术技术活动更是 Python 工程师需要也是想要了解到的内容，本文我站着说话不腰疼地也对这些主题闲扯几句吧。

三个主题的 Slide 地址是：https://github.com/Python-Meetup-Peking/PMP_slide，你也可以通过文末的「阅读原文」到达。我下面的内容会提到主讲人幻灯片中的一点内容，建议大家先完整看过 PPT 再来看本文效果会更好。

asyncio 和它的朋友们

asyncio 是 Python 3 官方的解决方案，也是 Guido van Rossum（Python 创建者，简称 GvR）主推的，我在之前的博文 我为什么不喜欢 Gevent 提到过我是比较认同 asyncio，不认可 gevent 的，我也说过 asyncio 的生态还远远没有建立，现在基本都只能算是玩一玩。asyncio 是非常有革命性意义的，直到它大家当做基本常识一样的被认可需要一个过程，这个过程看起来还比较长，我认为的原因有下面这么几点：

  1. 迁移成本太高。首先是 Python 2 到 Python 3 的迁移，并不是安装一个库就完事了，而且现在大部分公司在 Python 2 下的产品和服务运行良好，迁移得有值得的收益，所以现阶段不能说服 boss 干这件事，也让大家没了动力。
  2. 使用后的效果不突出。前年使用 asyncio 发现确实比之前的方案都要快，可以翻之前的内容，不过这个快并不是一个质的飞跃，而只是一个效率的提升，当效率没有成倍的提高的时候，你很难综合的决定为了那百分之 XX 的提升来做这么大的改变，毕竟现有的效率也没有出现瓶颈。
  3. asyncio 改变了编程习惯。asyncio 的作者们已经很努力的让开发者感受不到这种变化，但是 asyncio 用起来需要一整套的开发习惯的支持，简单地说：并不是你用了 aiohttp 你的 web 请求就都是异步非阻塞的了。请求到回应过程中某个地方没有注意阻塞了直接让效果大打折扣，但是如果你对业务以及 Python 和相关的库不熟很多时候这种问题是很难发现和杜绝的。
  4. 没有大公司出来背书，也鲜有重要项目宣称支持 asyncio 版本的驱动并及时维护。举个例子，aioredis 接口和 py-redis 参数不一致，一些常用的开源项目的更新迭代需要对应驱动也跟上，要不然开发者就会很尴尬。主题中主讲人提到了 https://github.com/aio-libs 这个组织，组织下面有些 aio 的驱动，不过这是一个民间组织，大部分开发者都是俄罗斯人，其实没有 Python 核心开发者参与的，自娱自乐成份要更多一些，质量上我是不放心的。如果哪天豆瓣上了 asyncio，我们肯定会选择自己维护一份相关的驱动，而不用社区性质的。其实在 Github 看到的大部分 asyncio 项目都不是官方的。大部分 Python 核心开发者在自己的公司也没有推这件事，只有少量的核心开发做了 asyncio 支持，比如 MongoDB 就有官方的 motor。

说了这么多消极的，那么我们能给 asyncio 这个生态做点什么？

  1. 多多用 asyncio 做项目，多写一些 asyncio 相关的文章，让更多人了解它接受它。
  2. 能力范围内造造常用工具的驱动，或者参与进来给现有项目提交 PR，你们可能不知道 Flask 刚流行那会插件系统的繁荣场景，其实做这个事情并没有那么难，整的理解 asyncio 之后，驱动就是一些套路罢了。

Python 性能调优

性能调优是开发者一直很关注的话题，在我的《Python Web 开发实战》中也介绍了很多的我常用的工具和使用方法，这个主题的内容基本覆盖了，唯一在书中没有提到的是 pyflame，不过之前在转载 Glow 的一篇《 Python web 应用性能调优 》时也提到了。

现在大家也能知道大家平时用的工具都差不多，倒没有秘籍。我其实更想说的是性能调优要求工程师平时要很关注到服务器资源的指标，及时发现问题，并且愿意花时间去分析和定位问题。

Python 在一家创业公司中的应用

清风老师早早的使用上了 Python3，羡慕。当然这也是由于没有历史包袱的原因。在老师介绍「Python3 带来了哪些好处」的时候提到：

1. 带来了类型检查 2. 不再被字符串编码问题折磨

第二点是很多人的痛就不提了，我来讲下对类型检查的看法。无独有偶，今年 Pycon 上海唯一能看的洪教授所在的爱因互动的主题演讲「Building Chatbot Service」中也提到了 Type Hint（当然也提到了 asyncio）。我之前提到过我不喜欢 TypeScript（当然原因复杂得多），所以答案是我对类型检查持保留意见（甚至反对）。当然这部分在一开始也在 Python 社区产生过分歧，我不喜欢的原因有几点：

  1. 我觉得 Python 就应该走简洁的路线，加上类型检查（哪怕是非强制的）让代码看起来臃肿不舒服，如果哪天 Python 强制要这么干，我就不再❤️它了。
  2. 类型错误造成的错误主要是由于工程师不了解业务需要和对自己写的代码没有充分理解才会出现，当然这还有异常处理的考虑的经验问题。靠类型检查来查出来，本质上是对工程质量的不信任。

当然类型检查这种方式可以极大的减少了代码出错的几率，让问题更早的暴露出来，这在实际生产环境中确实是有意义的，比如核心的如支付系统，为了确保万无一失，用上类型检查我还可以认同。

第二个点是老师创业选择的框架是 Django，理由是：

  1. 对于长期项目更加利于维护
  2. 第三方库众多
  3. BUG 比较少
  4. instagram 也在使用 - 之前我也发过一个翻译分享 Instagram 的工程师 Hui Ding 说到：『一直到用户 ID 已经超过了 32bit int 的限额（约为 20 亿），Django 本身仍然没有成为我们的瓶颈所在。』

这些我都是认可的，Django 确实是 Web 开发首选。大家知道我一直是推荐 Flask 的，它对于初学者友好，但是并不是让大家止步于此。我不用 Django 最重要的是我日常工作中没什么机会用 Django，而更常用 Flask 的首要的原因是我对它很熟悉，我可以随便自由地玩出花儿来，大家在实际开发的时候应该都知道都要基于业务场景对相关第三方库要进行一些定制，有些可能都不合适提交给上游而只能自己维护一个版本，所以对 Web 框架的熟悉程度是选择的重要标准。我之前记得什么地方有人说「企业开发都是用 Django，Flask 就是玩具」这样的论调，一看就是知识太狭隘，框架学的也不好，一个框架学好了，学其他的真的很轻松的。

想想为什么我没有什么机会用 Django 呢？

  1. 我个人不喜欢 Django 的大包大揽的不灵活，不用它但是我有能力「造」
  2. 没有历史遗留项目的包袱牵扯我的精力
  3. 我身边的工程师也不喜欢它，不会主动选择它
  4. 很早前阅读它的代码，它耦合度很高，和 Flask 写代码的方式差别是很明显的，这种方式倒不是不好，优点是代码利用率很高，缺点是刚了解它的人来说阅读和理解代码耗时耗力，Flask 则反之，代码调用层级明确且关系简单。

清风老师说工作中也使用了 Flask，在适当的场景下选择最适合的框架，这才是优秀工程师应该做的。