print string不行，非得print(string)
array.count, array.length不行，非得len(array)
array.first不行，非得array[0]
更不要说现在用 ipython notebook, 结果补完没有()，于是打完 print 还要接着的打括号...
用 Ruby 的时候不觉得好，换语言了才觉得，唉....
================ 吐槽一下，第二弹 p 为数组，求其均值，标准差
p_mean = np.mean(p)
theo_sd = np.sqrt(p_mean*(1-p_mean)*np.mean(1./n))
obs_sd = np.std(p)
mean(p)，为什么就不能放到p.mean里面呢...std也是啊...
另外写那么多np，为何不能省略掉啊....
第三弹，matplot
http://stackoverflow.com/questions/30240601/python-matplot-how-to-set-auto-offset/30241045#30241045
- 画图没有自动边界，得手动设置
python points = [(0,0),(0,1),(1,1,),(1,0)] for point in points: plt.plot(point[0], point[1], 'o') plt.show()这样画出来，4 点都在角上...怎么看 - 画图需要 Zip 点坐标，而不是支持直接画点
python points = [(0,0),(0,1),(1,1),(1,0)] xs, ys = zip(*points) plt.plot(xs, ys, 'o')非得zip一下 -
array.shuffle想要改变一个 array 的顺序，是不能这样的python import random rectangle = [(0,0),(0,1),(1,1),(1,0)] # I want something like # disorderd_rectangle = rectangle.shufflehttp://stackoverflow.com/questions/30253198/python-shuffle-and-create-a-new-array/30253390#30253390 =============== 第 4 弹numpy里面的 views 和 news。真是不知道为什么要这样.... 如果做 data intensive 的代码（其实就是 scipy）,np.array真是写到烦，难道就不能把np.array和本身的[]合并起来么
嗯，其实 len(array) 是 array.__len__() 的语法糖...
不加括号的 print 在 python 2 是可以的，但 python 3 不行...
array[start:stop:step] 挺强大的，不过哲学是只用一种方法操作，所以没有 array.first ...
list comprehension 也挺好使，比较适合简化一些需要 map + filter 才能完成的操作
括号不能省，显胜于隐嘛，哲学如此，2 里的 print 语句违反语言设计的很多原则。
ruby 是比 python 特性更多，但可读性有时候就牺牲了。
而且你举例的几个都比较鸡毛蒜皮吧，我开始用 ruby 还觉得怎么要写这么多 end 太蛋疼了
#11 楼 @chiangdi #12 楼 @spacewander
对。因为没有 end 或者 } ，lambda 要支持多行，会产生语法上的二意性。。。。。。所以 python 的 lambda 是半残废的。
上面有人说，ruby 代码比 python 少，是因为 ruby 糖比较多。比如脱离 active_support，ruby 写起来要麻烦很多。
我们现在写 method call 也都加括号，｀print(string)`，照着 Airbnb 的 style 来的。https://github.com/airbnb/ruby#method-calls
写习惯了觉得很好，意思很清楚。
Python 里我倒是从来不用 lambda……
而且 python 没有 ruby 的 &:length 这种语言级的简写……
array_of_arrays.map(&:length) => map(len, list_of_lists)
楼主，
print string 不行，非得 print(string)
python 这个有它的好处，不知道你是否踩过 ruby 的这个坑：
def m(a, b)
p a,b
end
m 1, 2
m(1, 2)
m (1, 2)
有吐槽的功夫不如用 ruby 好好的做些东西出来，我还想吐槽 ruby 的什么都要加 end 呢，但是相比这些语言带给我们生产上的便利，这些小的不如意的地方完全可以忽略。
python 相对麻烦一些
import operator
upper = operator.methodcaller('upper')
list =[['a', 'b', 'c', 'd'],['e', 'f', 'g', 'h'], ['i', 'j', 'k', 'l']]
print [map(upper, sub_list) for sub_list in list]
# [['A', 'B', 'C', 'D'], ['E', 'F', 'G', 'H'], ['I', 'J', 'K', 'L']]
但如果只是一级，python 可以这样写
>>> string_list = ['a', 'b', 'c']
>>> [text.upper() for text in string_list]
['A', 'B', 'C']
#24 楼 @greatghoul 这种类型确定的其实倒用不上 operator ，直接用 str.upper 就行的。。。
而且实际一般人还是用列表解析了……
@cqcn1991 from numpy import 就不用 np 了。。。
关键在于 Python 是不能乱改内置类的。。。不像 Ruby 给某些类随便加上几百个方法。。。
我也能说，用 Python 很久之后，觉得用 Ruby 给类实例加属性加方法非常不方便。。。
只要自己用的开心就好嘛。
记得前一阵子 Weibo 上，一个 Erlang 的大神 和 一个 Go 语言的大神 为了一个 C++ 的库吵了起来，本来两人以前还是朋友，结果只是为了一个技术上的观点，朋友都做不成了。
技术并不是生活的全部，通过技术讨论来结识更多的朋友，本应该是一件很高兴的事。
刚开始 java 转 ruby 的时候不习惯，erb 写多了写 haml 也一样的感觉，ruby 写多了又写 python 觉得不太习惯，prototype 写多了些 jquery 也不太习惯，android 后写 IOS 也这样，再后来习惯了也就又习惯了，总是要不停的去习惯一些以前不习惯的东西，就好比从上学到社会。。。纯扯淡
#39 楼 @greatghoul 我个人是不大喜欢使用你所描述的那种方式的。主观原因无非是我觉得这已经踩到所谓“trick”，“奇技淫巧”，“hack”的边缘了。客观上来说适当的使用 list comprehension 也是更加 Pythonic 的方式，而且 Python 的所谓哲学强调特定的事情只用一种特定的方式来实现。
这里稍微多说一点，避免不必要的误解，也希望能给大家略微开阔一下思路。我感觉 Python 这个语言表面上看勉强算是“优雅”（这依然是有争议的），但是稍微往深处走一些，就会发现仅仅在 Python 这个核心中，出于各种原因，就存在着许多看上去不那么优雅的东西，包括许多的“hack”。仅就我个人所知举例来说，我不喜欢在标识符头尾出现的各种下划线，不喜欢 Python 受限的 lambda 和蛋疼的作用域、闭包，讨厌 Python 2 和 py3k 的分裂，Python 的面向对象也有一些混乱。但是同样出于各种原因，Python 确实有足够的灵活性，也确实足够强大，所以很有用，但是在语法层面我并不觉得 Python 十分高明。
依然是 digression 内容，对于编程语言（的语法）这个问题，存在两种看法，一种认为编程语言应该类似自然语言，同时“易写”“易读”，另一种认为应该尽量严格，专业，就算外行人看了完全不明觉厉也无所谓，同时应该“易写”“易读”。注意这两个“易读”是不同的，前者是说我看了代码立马就知道是什么意思，因为很像自然语言，很符合一般人的思维，后者是说我看了代码立马就知道是什么意思，因为逻辑体现的很严密，很“explicit”，很符合数学家的习惯。在我所接触的范围里，前者的极端是 AppleScript，后者的极端是 C++。
我之所以特别关注这个问题，是因为我一直需要一种语言作为游戏引擎的脚本语言。我希望它能用优雅的语法定义引擎中的逻辑，因为引擎主要是面向非程序员的，所以要求直观，门槛低。我个人认为从理论上来讲，最合适的是 Ruby，因为其实我需要的是一种灵活的 DSL，这确实是 Ruby 所擅长的。但是 Ruby 和 Python 在一开始就因为性能等其他问题被否掉了。我尝试过 Lua，我认为 Lua 在理论层面上的设计是十分优雅的，同时借助 LuaJIT，可以获得不凡的性能。但是 Lua 的特性集为了保持其优雅和轻量搞得有些局限，并不足以满足我的需求，并且因此也产生了很多类似 Python 中的 "hack"（具体可以参考云风等人的博客和作品）。现在在尝试 JavaScript，我承认 JavaScript 确实也十分 dirty，但是确实很灵活，经过变态的优化之后速度也很好。不过我并不打算直接用 JavaScript 解决问题，而是借助于建立在其基础上的更加优雅的 CoffeeScript，以及更加严格的 TypeScript，所以说生态圈也算是 JavaScript 的另一大优势。
#41 楼 @secondwtq 欢迎关注 http://human-lang.org ，在解决软件复杂度的同时，也符合人类思维的一般习惯。
语法层面的构思在 https://github.com/human-lang/examples/blob/master/poignant.human 这里也有。
