楼主，你可以先买个小的（先不说后面会不会后悔买小了），老破小(但要地段好)也行。

你提到抵御风险， 风险来了，直接把房子卖了抵御风险。另外我们再额外考虑两种情况： 如果通胀， 你把现金捏在手里， 是抵御不了风险的；如果通缩，经济萧条，不要说你的工资降低，可能你的工作都保不住，你又拿什么抵御风险呢？靠着之前攒的现金么？

另外， 留在大城市，更多的还是希望自己能有机会成长，且工资上涨（不然和你说的“回去当收银员，服务员，店员”有什么区别）。 如果再过个几年，工资涨了，房贷也会越来越容易还、到时候每个月的公积金都能抵扣你的大部分房贷，更不会等到 20 年，30 年后才把房贷还完。

你要用发展的眼光看待这个社会，以及发展的眼光看待自己。

你直接去她的城市或者附近的城市， 你换工作， 她不用换。 就可以了嗷？

楼上的部分朋友们, 是不是没分清 Visual Studio 和 VS Code...............

@ifoolish 嗷没注意看评论抱歉 =。=

@ifoolish 老哥，9102 年了，有必要把 装饰器 + yield + raise 的写法改为 async await return 了。

竟然没有人提 Thought Works

美洽里有技术大牛。极强~

你如果确实有同步的库需要在异步环境执行，可以参考 https://stackoverflow.com/questions/22190403/how-could-i-use-requests-in-asyncio

asyncio.sleep 不是 async.sleep，打错

你应该先学习一下
1. 事件驱动、IO 多路复用 的知识(CSAPP 和 UNP 里有讲)。
比如先学习一下 select/poll 系统调用，OSX 下的 kqueue, 或者 Linux 下的 epoll(epoll_create, epoll_ctl, epoll_wait)的系统调用知识。
2. Python 本身的 yield, 和 send 分别实现了函数运行时的挂起和唤醒，丢到双端队列里，配合事件驱动每次去取。

然后再回头来看 asyncio 里是如何使用事件驱动的。比如你提到的 async.sleep. 实际就是下一次 epoll timeout 时的返回。

---

Tornado 早期自己利用 epoll 写了事件驱动的源码， 前期也有替换 asyncio 的事件循环的代码： http://www.tornadoweb.org/en/stable/asyncio.html 后来的版本，**似乎**和 asyncio 做了兼容。

另外，从写代码的角度，你可以把直接使用 async await 语法, 而不使用装饰器： http://www.tornadoweb.org/en/stable/guide/coroutines.html#native-vs-decorated-coroutines

另外，《 Python Cookbook 》里也有使用事件驱动来实现同时 handle 多个请求的例子，都可以参考着学习一下。

@scriptB0y 闭包 在 Fluent Python 里是有讲的。

《 Fluent Python 》 一生推

@lihongjie0209 你一个用 Java 的，专门开了一篇帖子让 Python 和 Golang 的撕 x。 可以的，老哥。

@lihongjie0209 所以您有，用 golang 和 aiohttp(loop 使用 uvloop)分别写一个 查询一条 MongoDB 的数据 的 server，做一下性能测试么。

您可以参阅 Python Cookbook Chapter 8: 8.7: Calling a Method on a Parent Class 这一小节。

super 的调用顺序实际上，与最终该类的 MRO 的顺序有关。你可以从 D.__mro__ 打印出类 D 的类继承顺序。
比如您给出的两个例子，的 MRO 分别为
(__main__.D, __main__.B, __main__.C, __main__.A, object)；
(__main__.D, __main__.C, __main__.B, __main__.A, object)
如何生成 MRO 顺序，就是 cookbook 里提到的 https://en.wikipedia.org/wiki/C3_linearization 了。

对于， “为什么没有经过 A，输出 init A... ” 你可以参考 Python Cookbook，第 8 章关于 super 的描述。 类 B 里 show 的 super，实际上调用的是类 C 的 show。 而类 C 的 super 已经被你注释掉了。

@hourann 嗯嗯。http://cn.pycon.org/2018/city_chengdu.html