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 点都在角上...怎么看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.shuffle
http://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 这里也有。