桌面版的是 python2 ，服务器的是 python3 ，记得他们是这样说。毕竟要跟上流统一

1. 直接按普通的 mock 返回结果就可以了，比如像一楼说的。 tornado 测试的时候会堵塞 IOLoop 直到返回结果，你当同步代码来用就可以了。比如你将 gen.coroutine 换成 tornado.testing.gen_test ，那么你执行的代码的时候就是堵塞。

2. 之所以要 raise tornado.gen.Return 是一个 hack ，是 python 2.7 时代不允许 generator 里面有 return 的 hack ，因此就通过 raise 一个异常来解决这个问题。你若是使用 python 3.5 就可以直接 return 。而且你还可以使用 async 跟 await 两个关键字来达到更好的语义。

若是生成文件都在一个文件夹里面的话，你 add 那个文件夹就好了

@racechao @Draven 真是曲高和寡，好东西就是这样，最能吸引人的往往是最简单的。

@gevin 没有观点，选合适的， C++性能高但初学者用会很容易崩掉自己的腿。道理就是这样。我只是觉得仅仅一个结论不能达到你想要分享的初衷。
因为这样一个结论很多时候只能带来，『对啊， Django ORM 就是强』，『开玩笑， SQLAlchemy 才是最好的』，『 Pony ORM 才好，其他都是垃圾』这样无意义的回应。
记得一次与一位大牛聊天，他说编程中我们现在已经有很多资源了，但是好软件，好产品一样很少，这个原因就是人们缺少对事物的了解，以至于无法将资源合理利用。
所以我认为，我们在网上发表我们的观点时候是不是可以尽量地将我们的思考方式展现给大家呢？你是如何得出这个结论，我认为这才是关键，这才是大家想看到的『渔』之道。这样的文章无论是初学者还是中级谋求突破的开发者都会喜欢看到。
若是题主你能做到此步，我相信你的文章就会更精彩

@chewuhe windows 没有这个 fd 的限制，在 windows 上你操作的 sockets 仅跟你的机器资源有关
资料来源： https://msdn.microsoft.com/en-us/library/windows/desktop/ms739169(v=vs.85).aspx

@gevin 所以你要说明白，你一句 Django ORM 综合起来比 SQLAlchemy 强，新手还以为是 Django ORM 特性多，性能高。
很多时候就是这样，高灵活性以及低抽象成本必然伴随高的学习成本。
你分享你的具体看法观点，我们都来切磋切磋，这样你我才能进步嘛，仅抛一个结论就出来跟『 vim 大法好』这样有什么区别:-)

其他的我就不发表观点了，我只想说『 Django 的自带 ORM 非常优秀，综合评价略强与 SQLAlchemy 』这样的评价没有能说明任何问题，以下是我的见解

在 Python 以及关系型数据库 ORM 中对应的 Django 跟 SQLAlchemy 可谓两个很典型例子。 Django 很明显是从 RoR 里面得到启发，因此很多时候它也很像 RoR ，比如 Django 就是典型的 Active Record,数据库里面的行直接映射成 Model 的实例，并且所有对数据库的操作是直接与实例绑定，例子即为:
New.objects.create(title='sport', author_name='Neo')
对象（实例）不单单封装了数据库表里面的一行（数据）还封装了数据库的操作，以及在这些数据上面有领域逻辑，比如：
User.objects.create_user('john', '[email protected]', 'johnpassword')
Active Record 对象不仅仅有访问数据的一些方法，而且还有领域逻辑（我们实际的业务逻辑），而且领域模型中的数据跟数据库基本吻合

而 SQLAlchemy 的领域模型就不一样， SQLAlchemy 是基于 Data Mapper 设计而成的。 SQLAlchemy 的数据操作是不能直接作用与实例，它是通过一个 proxy(Data Mapper)来维护领域模型（大致上对应 SQLAlchemy 里面我们定义的 Model ）跟数据库表的映射关系，它最大的优点便是数据库表跟领域模型是两个独立的概念，他们之间的关系是解耦的，因此他们可以独立演变，这之后需要做的只不过是我们去更新 Data Mapper 。因此 SQLAlchemy 给我的最大印象就是，它可以实现多态，比如一个 Animal 类可以对应数据库里面的 Dog 跟 Cat 表，以至于一个 Animal 的 cry 方法可以返回"woof"或者"meow"

同时 SQLAlchemy 还有 core 模块去提供高效率的查询（效率可以达到 raw sql 的水平）同时它的查询方式跟 Django 比起来更多样，比如 SQLAlchemy 的 ORM 模块能提供跟以下 SQL 语句对应的查询方式（仅通过一个查询）：
select username, score from users join classmates on users.user_id=classmates.user_id where classmates.age > 20 group by (users.username, MAX(users.score));

我个人是觉得 SQLAlchemy 从功能以及灵活性来说都是源于强于其他 ORM （ python 以及对应关系型数据）。但是它跟 Django 比起来就是它有一个很陡峭的学习曲线，这是它的最大缺点。因此我是建议简单项目或者与 Django 相关的使用 Django ORM ，其他的话，若是你们团队协作，而且会有领域模型跟数据库表演进速度不一致的情况，那么选用 SQLAlchemy 是一个不错的选择。

@leonlh
同意 @wittyfox 的话，你们工作流或者分工不合理，要不然怎么会整天出现冲突。
你这样的目前这样操作是合理的，我是看不到有更少的步骤了，你当然可以写 alias ，但只能减少你命令输入的次数而已，出现冲突还是得人工干预， 也就是说你解决了冲突之后当然要 git rebase --continue ，这个步骤是自动不了的，要不然你不输入 git 怎么知道你解决了冲突了呢？

@leonlh
两个人互相提供接口？循环引用？
而且 rebase 本来就是像你说的一样啊，有冲突才会停止啊，只不过是你多了一步缓存你当前还没完成的内容而已。你像一楼说的 commit 就没事了。不要一个 commit 几千行啊， review 的人都要死了

关键就是你拉代码为什么会有这么多冲突？你有冲突当然要人工干预啊。

我的建议就是多执行 git pull --rebase ，你的代码要多分模块，多提交，多 push

冲突多没办法的，什么方案都救不了