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是非常有革命性意义的，直到它大家当做基本常识一样的被认可需要一个过程，这个过程看起来还比较长，我认为的原因有下面这么几点：
- 迁移成本太高。首先是Python 2到Python 3的迁移，并不是安装一个库就完事了，而且现在大部分公司在Python 2下的产品和服务运行良好，迁移得有值得的收益，所以现阶段不能说服boss干这件事，也让大家没了动力。
- 使用后的效果不突出。前年使用asyncio发现确实比之前的方案都要快，可以翻之前的内容，不过这个快并不是一个质的飞跃，而只是一个效率的提升，当效率没有成倍的提高的时候，你很难综合的决定为了那百分之XX的提升来做这么大的改变，毕竟现有的效率也没有出现瓶颈。
- asyncio改变了编程习惯。asyncio的作者们已经很努力的让开发者感受不到这种变化，但是asyncio用起来需要一整套的开发习惯的支持，简单地说：并不是你用了aiohttp你的web请求就都是异步非阻塞的了。请求到回应过程中某个地方没有注意阻塞了直接让效果大打折扣，但是如果你对业务以及Python和相关的库不熟很多时候这种问题是很难发现和杜绝的。
- 没有大公司出来背书，也鲜有重要项目宣称支持asyncio版本的驱动并及时维护。举个例子，aioredis接口和py-redis参数不一致，一些常用的开源项目的更新迭代需要对应驱动也跟上，要不然开发者就会很尴尬。主题中主讲人提到了 https://github.com/aio-libs 这个组织，组织下面有些aio的驱动，不过这是一个民间组织，大部分开发者都是俄罗斯人，其实没有Python核心开发者参与的，自娱自乐成份要更多一些，质量上我是不放心的。如果哪天豆瓣上了asyncio，我们肯定会选择自己维护一份相关的驱动，而不用社区性质的。其实在Github看到的大部分asyncio项目都不是官方的。大部分Python核心开发者在自己的公司也没有推这件事，只有少量的核心开发做了asyncio支持，比如MongoDB就有官方的motor。
说了这么多消极的，那么我们能给asyncio这个生态做点什么？ - 多多用asyncio做项目，多写一些asyncio相关的文章，让更多人了解它接受它。
- 能力范围内造造常用工具的驱动，或者参与进来给现有项目提交PR，你们可能不知道Flask刚流行那会插件系统的繁荣场景，其实做这个事情并没有那么难，整的理解asyncio之后，驱动就是一些套路罢了。
Python 性能调优
性能调优是开发者一直很关注的话题，在我的《Python
Web开发实战》中也介绍了很多的我常用的工具和使用方法，这个主题的内容基本覆盖了，唯一在书中没有提到的是pyflame，不过之前在转载Glow的一篇《Python
web 应用性能调优》时也提到了。
现在大家也能知道大家平时用的工具都差不多，倒没有秘籍。我其实更想说的是性能调优要求工程师平时要很关注到服务器资源的指标，及时发现问题，并且愿意花时间去分析和定位问题。Python 在一家创业公司中的应用
清风老师早早的使用上了Python3，羡慕。当然这也是由于没有历史包袱的原因。在老师介绍「Python3带来了哪些好处」的时候提到：
1.带来了类型检查
2.不再被字符串编码问题折磨
第二点是很多人的痛就不提了，我来讲下对类型检查的看法。无独有偶，今年Pycon上海唯一能看的洪教授所在的爱因互动的主题演讲「Building Chatbot
Service」中也提到了Type
Hint（当然也提到了asyncio）。我之前提到过我不喜欢TypeScript（当然原因复杂得多），所以答案是我对类型检查持保留意见（甚至反对）。当然这部分在一开始也在Python社区产生过分歧，我不喜欢的原因有几点： - 我觉得Python就应该走简洁的路线，加上类型检查（哪怕是非强制的）让代码看起来臃肿不舒服，如果哪天Python强制要这么干，我就不再❤️它了。
- 类型错误造成的错误主要是由于工程师不了解业务需要和对自己写的代码没有充分理解才会出现，当然这还有异常处理的考虑的经验问题。靠类型检查来查出来，本质上是对工程质量的不信任。
当然类型检查这种方式可以极大的减少了代码出错的几率，让问题更早的暴露出来，这在实际生产环境中确实是有意义的，比如核心的如支付系统，为了确保万无一失，用上类型检查我还可以认同。
第二个点是老师创业选择的框架是Django，理由是： - 对于长期项目更加利于维护
- 第三方库众多
- BUG比较少
- instagram也在使用 - 之前我也发过一个翻译分享 Instagram 的工程师 Hui Ding 说到：『一直到用户 ID 已经超过了 32bit int 的限额（约为 20 亿），Django 本身仍然没有成为我们的瓶颈所在。』
这些我都是认可的，Django确实是Web开发首选。大家知道我一直是推荐Flask的，它对于初学者友好，但是并不是让大家止步于此。我不用Django最重要的是我日常工作中没什么机会用Django，而更常用Flask的首要的原因是我对它很熟悉，我可以随便自由地玩出花儿来，大家在实际开发的时候应该都知道都要基于业务场景对相关第三方库要进行一些定制，有些可能都不合适提交给上游而只能自己维护一个版本，所以对Web框架的熟悉程度是选择的重要标准。我之前记得什么地方有人说「企业开发都是用Django，Flask就是玩具」这样的论调，一看就是知识太狭隘，框架学的也不好，一个框架学好了，学其他的真的很轻松的。
想想为什么我没有什么机会用Django呢？ - 我个人不喜欢Django的大包大揽的不灵活，不用它但是我有能力「造」
- 没有历史遗留项目的包袱牵扯我的精力
- 我身边的工程师也不喜欢它，不会主动选择它
- 很早前阅读它的代码，它耦合度很高，和Flask写代码的方式差别是很明显的，这种方式倒不是不好，优点是代码利用率很高，缺点是刚了解它的人来说阅读和理解代码耗时耗力，Flask则反之，代码调用层级明确且关系简单。
清风老师说工作中也使用了Flask，在适当的场景下选择最适合的框架，这才是优秀工程师应该做的。
版权声明：本文由 董伟明 原创，未经作者授权禁止任何微信公众号和向掘金(juejin.im)转载，技术博客转载采用 保留署名-非商业性使用-禁止演绎 4.0-国际许可协议
python