没准是兼容代码呢.

这个要看项目的目录结构, 一般可以通过在 `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 造成十亿美元损失这一说了.

Linux 这么酷的桌面 CPU 吃的消吗? 而且我觉得桌面再漂亮也没啥用, 总不能天天对着桌面干活. 2333

就像我费劲找了一张好看的墙纸, 最后发现压根就没机会看.

@leyle 比加 u 更省劲而且更好的兼容 Python3 是在每个模块顶部引入:

from __future__ import unicode_literals

现在新的模块统一从 __future__ 导出以下几个:

from __future__ import unicode_literals, print_function, division

@higrase 我是看了 1/2, 扔在那就没有想拾起来的兴趣了.

@slideclick #4 one thing one way 我没记错的话应该是针对 Perl 提出的, 应该主要指编码层面, 比如判断 None 值,
var == None 和 var is None 都可以实现, 但是应用 one thing one way 就是使用 var is None 才是正确的, 还有 in 的使用等等.

> .而 web 全栈或者后端这两个岗位都不是 one thing one way

one thing one way 应该和这个没有任何关系, 而且目前 Python Web 的整体生态还是不错的, 从框架的多样性, ORM, 模板引擎, WSGI 等等都说明 Python Web 开发已经很成熟.

python -m pip --version