s********k
发帖数: 6180 | 1 主要抱怨跟版上差不多：
1. 性能，我们有一个analysis engine跑的挺慢。
2. dynamic type。
后来发现1跟python关系不大，主要是DB设计问题，本来一个table可以解决的问题弄成
3个table，而且还query一个数据最多用处最小的table，不停做cache。修改之后速度
快多了。另外multithreading老是觉得有GIL的问题，做了一个测试系统下狠心去掉
multithreading用coroutine性质的twisted，性能也是大幅提升。
2的话没办法，因为集成legacy code，出错没法编译开出，有些时候要上线运行才知道
。老大虽然抱怨，但是他想重新用C++写的话自己也头大，因为1解决之后他自己感觉爽
多了，另外部署了更好的测试系统，也就不咋提2了。 |
p**o
发帖数: 3409 | 2 dynamic typing 带来的问题主要靠 文档 和 测试 来解决，
python 其实很适合 test-driven dev
像下面这位仁兄这样搞类型检查也行，但性能损失会很大
http://www.newsmth.net/bbstcon.php?board=Python&gid=102341
【在 s********k 的大作中提到】
: 主要抱怨跟版上差不多：
: 1. 性能，我们有一个analysis engine跑的挺慢。
: 2. dynamic type。
: 后来发现1跟python关系不大，主要是DB设计问题，本来一个table可以解决的问题弄成
: 3个table，而且还query一个数据最多用处最小的table，不停做cache。修改之后速度
: 快多了。另外multithreading老是觉得有GIL的问题，做了一个测试系统下狠心去掉
: multithreading用coroutine性质的twisted，性能也是大幅提升。
: 2的话没办法，因为集成legacy code，出错没法编译开出，有些时候要上线运行才知道
: 。老大虽然抱怨，但是他想重新用C++写的话自己也头大，因为1解决之后他自己感觉爽
: 多了，另外部署了更好的测试系统，也就不咋提2了。
|
g*****g
发帖数: 34805 | 3 dynamic typing用来做脚本，包括UI问题不大。用来做backend service，成本比较高。
这年头软件基本上都是under-tested，产品环境发现的bug，修复的成本比开发环境的
高太多。static typing可以减少很多无谓的bug。
【在 p**o 的大作中提到】
: dynamic typing 带来的问题主要靠 文档 和 测试 来解决，
: python 其实很适合 test-driven dev
: 像下面这位仁兄这样搞类型检查也行，但性能损失会很大
: http://www.newsmth.net/bbstcon.php?board=Python&gid=102341
|
s********k
发帖数: 6180 | 4 但是事实证明大部分bug跟dynamic关系不大，都是系统的bug，语法bug肯定都会在test
出发现。当然有一些exception的bug，但是static typing的也会有这个问题吧？
当然我们并发量不大，肯定不是跟NFLX一个级别的。
高。
【在 g*****g 的大作中提到】
: dynamic typing用来做脚本，包括UI问题不大。用来做backend service，成本比较高。
: 这年头软件基本上都是under-tested，产品环境发现的bug，修复的成本比开发环境的
: 高太多。static typing可以减少很多无谓的bug。
|
g*****g
发帖数: 34805 | 5 我说的不是逻辑的bug，是最简单的诸如类型不能转换这样的bug，我们的测试不能覆盖
每个分支。
test
【在 s********k 的大作中提到】
: 但是事实证明大部分bug跟dynamic关系不大，都是系统的bug，语法bug肯定都会在test
: 出发现。当然有一些exception的bug，但是static typing的也会有这个问题吧？
: 当然我们并发量不大，肯定不是跟NFLX一个级别的。
:
: 高。
|
s********k
发帖数: 6180 | 6 这个倒是确实是个问题，有些时候会导致莫名其妙的exception。尤其是有些大数据结
构的转换。
我们后来解决这个问题的方案是尽量不用私有的数据结构之间转换，communication
channel都是标准的JSON。而且逐渐把一些私有数据结构也往JSON上靠。最麻烦的部分
在legacy code的XML部分。其他还好。
【在 g*****g 的大作中提到】
: 我说的不是逻辑的bug，是最简单的诸如类型不能转换这样的bug，我们的测试不能覆盖
: 每个分支。
:
: test
|
s********k
发帖数: 6180 | 7 不过python好的是很多性能瓶颈都能找到很好的库很快地去除。比如用twisted代替原
来的multithreading，性能提高了几倍。而且code change能做到可控制范围。
【在 s********k 的大作中提到】
: 这个倒是确实是个问题，有些时候会导致莫名其妙的exception。尤其是有些大数据结
: 构的转换。
: 我们后来解决这个问题的方案是尽量不用私有的数据结构之间转换，communication
: channel都是标准的JSON。而且逐渐把一些私有数据结构也往JSON上靠。最麻烦的部分
: 在legacy code的XML部分。其他还好。
|
c****e
发帖数: 1453 | 8 Why not using Thrift to toughtly control data contract?
【在 s********k 的大作中提到】
: 这个倒是确实是个问题，有些时候会导致莫名其妙的exception。尤其是有些大数据结
: 构的转换。
: 我们后来解决这个问题的方案是尽量不用私有的数据结构之间转换，communication
: channel都是标准的JSON。而且逐渐把一些私有数据结构也往JSON上靠。最麻烦的部分
: 在legacy code的XML部分。其他还好。
|
c****e
发帖数: 1453 | 9 twisted should port c# "await" over, the code would be less verbose.
【在 s********k 的大作中提到】
: 不过python好的是很多性能瓶颈都能找到很好的库很快地去除。比如用twisted代替原
: 来的multithreading，性能提高了几倍。而且code change能做到可控制范围。
|
s********k
发帖数: 6180 | 10 你说的是cross-language吧，我们不是cross-language，就都是python，但是比如在
local server和cloud之间这种交换，数据结构有些时候不太一样，当然很多事legacy
问题
【在 c****e 的大作中提到】
: Why not using Thrift to toughtly control data contract?
|
l********a
发帖数: 1154 | 11 可以用type(a)来做类型检查,还有个isinstance()函数也可以.感觉dynamic typing应
该不是个大问题.不过我没有用python搞过大项目,不大清楚实际应用中如何.
【在 p**o 的大作中提到】
: dynamic typing 带来的问题主要靠 文档 和 测试 来解决，
: python 其实很适合 test-driven dev
: 像下面这位仁兄这样搞类型检查也行，但性能损失会很大
: http://www.newsmth.net/bbstcon.php?board=Python&gid=102341
|
d***q
发帖数: 1119 | 12
twisted support a sugar called inlineCallbacks
you can do sth like yield await(2). It behaviors like "await" in C# 5.0.
【在 c****e 的大作中提到】
: twisted should port c# "await" over, the code would be less verbose.
|
