《代码整洁之道》里有提过，如果代码需要注释那就说明代码表达力不够，而且注释很容易不跟随代码更新从而误导读者（有可能是你自己）。如果你要为某段代码添加注释那么就应该考虑是不是应该换个名字或使用更加富有表达力的代码，如提取到单独的方法并起个好名称。

把下面基本书多撸几遍

- 《程序员修炼之道：从小工到专家》
- 《重构：改善既有代码的设计》
- 《代码大全》
- 《代码整洁之道》
- 《设计模式》

> 研发 + 带人 + 项目管理

简直我和做的一模一样

@snal123 要的, 但是要求基础好并且对技术有热情.

没准是兼容代码呢.

这个要看项目的目录结构, 一般可以通过在 `launch.py` 所在目录将 `python path/to/script.py` 替换成 `python -m path.to.script` 解决.

可以换位思考一下, 如果你负责面试你会当面告知应聘者结果吗? 如果答案是肯定的, 等有机会可以试几次, 也许你就会发现你也会拿这个当做委婉的拒绝. 因为当面拒绝会让部分人觉得很难堪, 如果得到这种答复又想进一步明确的得知答案(能接受被当面拒绝)为什么自己不多问一句呢?

写的更漂亮和语言关系不大, 推荐看:

- 代码大全
- 重构
- 程序员修炼之道
- 代码整洁之道

如果想要写更地道的 Python 可以看看 Python 高级编程, 把你的代码用 pylint/flake8 等工具过一遍, 根据输出调整代码.

我的 2016 款, 选带 bar 是因为带 bar CPU 2.9GHz. 不带 bar 2.3GHz

创建个 view?

@gouchaoer 不是加不加括号, 而是从一个表达式变成了函数, 引用 https://stackoverflow.com/a/6241519 提到的其中一个好处就是可以像如下方式使用 print:

>>> [print(x) for x in range(10)]

print 并不会对兼容性造成太多的困扰, 毕竟很少有库里直接使用 print, 而且 print 这种非常容易修改. 最大的不兼容就是底层使用 Unicode 重新实现, 同时严格区分了 字节序(bytes) 和 Unicode(str). 比如 Python2 中 bytes 和 unicode 可以相互比较, 但是在 Python3 中是不允许的:

Python2:

>>> b'abc' in u'cc abc' # True

Python3:

>>> b'abc' in 'abc' # TypeError

还有比如 Python2 中只要是字符串类型(str,unicode) 都有 format/decode/encode 方法, 但是 Python3 中仅允许 Unicode(str) 有 encode/format 方法, bytes 不允许有 format 方法, 等等等.

这样做的好处是让语言更加严谨, 其他一些库的不兼容可能主要是由于这个原因导致, 也有部分可能是破窗效应: 反正不兼容那就做些大调整, 比如换个名啥的.

还有一些类似 MySQLdb 这样的库不兼容是因为 Python3 的 C API 也不兼容, 导致这些用 C 写的扩展库不支持 Python3, 就像 #8 说的, 除非一些已死的项目(想 MySQLdb) 基本上都已经(或正在)同时兼容 Python2 和 Python3.

@donething #3 我们目前在尝试把在开发中的 Python2 项目迁移到 Python3, MySQL 连接库我们目前在尝试使用 https://github.com/PyMySQL/mysqlclient-python ,

检查一下是否存在相互引用导致 Handler 没有被回收. 因为 Tornado 会为每一个请求构建新的 Handler 处理请求. 如果当前 Handler 的 self 传递给其他对象保存, 同时又把该对应绑定到了 self 上就会产生内存泄露.

PS. 如果没有引起 OOM 就没啥大问题.

http://i.imgur.com/0QeZxki.png

是时候贴出这张图了.

export VIRTUALENV_NO_DOWNLOAD=1

参见 https://github.com/pypa/setuptools/issues/1042

为什么会有这方面的担忧? 难道发的 MacBook 还同时给其他同事一起使用?

rebase 可以让实现一个功能的多个提交紧凑的排列在一块, 并减少不必要 merge commit. git merge --no-ff 用于多人协作时将功能分支合并到长期分支, 好处是会生成一个 merge commit 便于回退和持续集成, 因为可以通过回退该 merge commit 来回退 merge 的所有 commit. rebase 在多人协作时使用不当会产生额外的提交会给其他人造成困扰.

任何语言重构如果没有测试和测试覆盖率保证的话都是火葬场吧, 编译型语言能保证编译通过还能保证运行时没问题? 保证逻辑正常? 如果可以的话也就没有 NULL 造成十亿美元损失这一说了.