@djyde 我记得有人研究的，这货是直接套用的 VB 和 MFC 貌似 http://www.zhihu.com/question/19770358

@myyou 我用的是 Flask-SQLAlchemy ，直接在配置文件中修改 SQLALCHEMY_POOL_SIZE 就可以了，详见 https://pythonhosted.org/Flask-SQLAlchemy/config.html#configuration-keys
我是在类中使用的，添加 __del__ 方法，使得该对象销毁的时候自动调用 session.close () 具体代码找不到了，大概是

def __del__(self ):
db.session.close ()
# 或者 db.session.remove ()
@sbmzhcn 我当时解决的并不是并行写的问题，是连接池溢出问题。对于并行写我没有研究过，当时用的方法是使用 Queue 到一个线程中统一写入。

@sbmzhcn 解决了，使用以下两点： 1. 将连接池加大，自己估算平均量 * 1.5 即可。在调用 SQLAlchemy 的类中加入 __del__ 方法，在该方法中调用 session.close () 即可。

30 美元。。。。这定价， PyCharm 才多少刀啊。

@jarlyyn 如果你女朋友常用 QQ 的话 ~ ~ ~ ~ ~

@jarlyyn 好吧，我的表达有错。那，除了难用的 TM 我们能不用 QQ 么，搜狗是不是关不掉的弹窗，家里给父母用的电脑一开机各种弹窗 ~
@fuxkcsdn 额，脱离 windows 好些年，用 windows 那会还是高中无知少年哈 ~

楼主的错在于：
1. 不是程序员却在折腾命令行
2. 带着 Windows 的意识去使用 Linux
3. mac 和 linux 的好处你不用，你偏要去折腾他不好用方面。人无完人。

另外，我想弱弱的问一句， windows 的流氓软件和各种弹窗广告， LZ 有没有觉得很优雅呢？

好奇，楼主为什么不用 windows 而去折腾 mac 和 linux ~ 为什么不在 mac 上装 windows 一了百了呢？
我出的价格比 107 楼高， 1500 怎么样？

@poke707 我发现了，取到的都是函数对象 ~
@lcqtdwj 并不是这样的，你可以自己试一试。原因是 @poke707 所说的。

@xiazi 哈哈，感谢你提供高质量讨论。
在我有限的职业生涯中高手菜鸟都见过，对于 DRY 、 KISS 这些编程箴言我个人觉得更多的是指导菜鸟，因为他们的代码往往重复、混杂。对于合格工程师，自然不必太强调这些，而对于他们，优雅的接口设计和稳健的代码实现才是他们关注的重点。对于抽象的层次，我们目前采用的方式是对非业务的通用功能抽象、对业务代码少抽象。比如，在目前项目中，我们的业务逻辑部分大多是直白的代码描述和接口调用，但对在权限管理、处理缓存、数据处理、异步操作（请求其他接口）、计数器等操作往往都是抽象出来。但同时，为了避免过度抽象，我们还要求在模型定义、业务接口调用等方面禁止使用继承。（对于王垠，在我学识尚浅的时候还是很崇拜他的，但后来玩的多了，发现他虽然还是正确的，但他讨论的层次（除编译优化）往往并不深入）

对于 with 等语言元素，用不用我想是属于个人风格的问题吧。大家喊了 lambda 这么多年 GvR 就是不改，他也算偏执的追求简洁吧，但 with enum 这些关键词、标准库，我想他们一定是经过设计者深思熟虑的存在的非常有意义的。对于 explicit is better than implicit 这个，我看过有些人写的代码，使用 value[n] 引用的方式修改不该修改的内容，在业务代码里写多层嵌套，滥用装饰器、闭包等特性，我也是反对的。

reactjs 所倡导的组件化，我也是支持的。多用接口，少用继承。接口可以保证调用明确，继承往往存在隐式转换（这也是我不喜欢 C++ Java 的原因）

我不喜欢 Ruby 的魔幻，热爱 Python 的简洁。 P.S 我是支持 Python 3 的。

@xiazi 抽象层的问题，我看到有很多人批评《重构》那本书中的观点，同样的有很多人反对设计模式。
但，至少我看到过的很多代码，将业务逻辑放给新员工，抽象层放给优秀的员工，这样可以更好的解决团队代码质量的问题。并且，很多包含技巧、重复的代码出现在业务层面，难道不是更容易犯错吗。对于 debug 和 测试，良好的构架和抽象可以分离不同层级的代码，降低耦合性，低耦合之后不是反而更容易测试吗？
不过，Python 的函数调用开销很多，这也是我一直头疼的。

@mengzhuo 额，您所说的问题我也听说过、见过。最原始的做法，是不是就是指的仅用基本的语句，高级特性（如自省、迭代器、生成器、装饰器）都不用呢？
不过我个人认为，可读性并不一定是指这样的。我们在工作中，规范上明确讲业务实现要代码、命名明确，抽象工具库的接口要简单易懂，抽象工具库的实现要多注释和文档、多测试。这样最容易出错和更改的业务部分保持代码的易读，接口调用明确。这样的代码可读性也是非常好的。
额，我从业时间短不敢多说，但，感觉还是和团队风格是不是有一些关系？

@AlexaZhou
动态语言大多有自省这一神奇的语言特性，很久看过一个帖子 http://www.cnblogs.com/huxi/archive/2011/01/02/1924317.html 将 Python 自省的，感觉不错，现在工作了用的也多。
我们团队在写各种抽象工具的时候，代码确实魔幻了一些，但那些库对外的接口一般的经过多轮讨论确定规范、无歧义、完全解耦、简单才会放给开发组用。（尤其是上了 DSL 之后，内部实现更魔幻了哈哈）所以，我们经常维护的业务代码确实可读性很有必要，但工具库的实现，咱 Python 到底可以完成什么样子呢？
@justahappy 这帖子 ~ 额 ~ 咱是好孩子不吵架的 :P

@bingwenshi 比如，这样做是不是装？

用装饰器将一个函数标记，初始化模块的时候遍历该模块中这部分被标记的函数，并对其做进一步操作
形如：
@ my_decorate
def func(): pass
这功能利用了 function 也是对象这一特点，动态添加其属性 func.__dict__['be_add'] = True

@Luzifer 《纽约时报：左撇子更优秀吗？》http://www.guokr.com/article/12307/
《[桥]当左脑遭遇右脑》http://songshuhui.net/archives/47806
http://site.douban.com/guokr/widget/notes/1670101/note/174768622/

@sa2852
@cqcn1991 果壳上不是辟谣了么，那是谣言

现在做互联网的，没淘宝千万pv体量的，还有多少在用 java 的？
EasyUI ~ 囧rz 好吧，我们学校老师接外包基本都用这个。
这个也算，技术应该是比较新的？