推荐学习书目
› Learn Python the Hard Way
Python Sites
› PyPI - Python Package Index
› http://diveintopython.org/toc/index.html
› Pocoo
值得关注的项目
› PyPy
› Celery
› Jinja2
› Read the Docs
› gevent
› pyenv
› virtualenv
› Stackless Python
› Beautiful Soup
› 结巴中文分词
› Green Unicorn
› Sentry
› Shovel
› Pyflakes
› pytest
Python 编程
› pep8 Checker
Styles
› PEP 8
› Google Python Style Guide
› Code Style from The Hitchhiker's Guide
这是一个创建于 4706 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 · 2013 年 2 月 27 日
这个站还用了ORCA 囧
 |
1
simomo2010 2013 年 2 月 27 日
“python写超过1000行代码就虐心”：
- 这个结论不知道怎么得出来的，或许是1000行代码都在一个函数里，然后里面有七八十来层‘if’分支，‘for’循环。不过话说回来 任何语言这么写都虐心 关于缺乏在编译阶段的bug检测的缺失： - 去年pycon us大会上 龟叔做的keynote speech 里也针对这点说了，靠编译器帮你检查bug这本身就是错误的，作为coder需要做的是编写合适的测试代码，提高测试的覆盖度，将bug发现在源头，而不是写完之后，就扔给编译器，让他给你差错 运行效率： - 这个就是老生常谈了，效率敏感的地方用c写，或者用cython也不错，pypy某些时候也是一种选择，还不能满足？好吧 那确实这个项目不适合python，但世上有多少项目是这样的呢？python并不能解决所有问题，只是能快速，优雅，方便的解决绝大部分问题而已 ”python是python之父的玩具“： - 我想这句话本身就是错的，python在最开始的时候 或许就是龟叔的一个玩具，但是在其后20多年的发展中，已经变成了一个凝聚了整个python社区心血的伟大的开源项目，虽然不清楚这位’Dr.菜‘是何许人也，但是我想不论是谁，都没资格用’玩具‘来评价它 |
 |
2
tioover 2013 年 2 月 27 日 via Android  1
该网站的安全证书不受信任！
|
 |
3
saharabear 2013 年 2 月 27 日
这网站自称技术第一的开源社区?
|
 |
4
clino 2013 年 2 月 27 日
不用对这种言论当真.
云风是QQ黑,C++黑,windows黑(软件开发方面),这几个我都蛮同意的. |
|
5
saharabear 2013 年 2 月 27 日 1
@clino 笑喷了,你不提我还真没注意(我读完了他们的帖子,你不提我真没注意到云风了躺枪),他们说云风是SB,就因为C++....笑喷了..
我觉得技术人员心直口快也足够让咱们这种技术圈子增加各种笑料了. 我不是C++黑,可是我几年都学不会C++. |
 |
6
phuslu 2013 年 2 月 27 日 1
很有说书人的范，我赞同部分观点，不过举例的部分"戏说"了。
目测此帖会火。 |
 |
7
G0dBlessMe 2013 年 2 月 27 日
哈哈
|
 |
8
armin 2013 年 2 月 27 日
https://avlog.avplayer.org/ 这是啥网站？！
|
 |
9
august 2013 年 2 月 27 日
樓主是不是有個姑娘跟你打賭了？
|
 |
10
keakon 2013 年 2 月 27 日
主观的东西就不说了，Python 历史比 Java 悠久啊…
|
 |
11
chaos186 2013 年 2 月 27 日
看完第一反应是：这是说相声吧
|
 |
12
kran 2013 年 2 月 27 日
看完这个 才知道自己已经不是最最底层的码农了 哇哈哈
|
 |
13
justfindu 2013 年 2 月 27 日
你们都不关注域名很奇怪么~
|
 |
14
isy 2013 年 2 月 27 日
|
 |
15
Asimov 2013 年 2 月 27 日
Python的确挺慢的，不过语法优美简洁，库比较齐全。挺好。
|
 |
16
raincious 2013 年 2 月 27 日
嗯……这个看个人喜好吧。我刚开始学Python的时候也不太喜欢它，现在我刚开始学Python。
|
 |
17
wenbinwu 2013 年 2 月 27 日
firefox告诉我证书有问题，我就没进去看
|
 |
18
RisingV 2013 年 2 月 27 日
解释形语言需要运行时排除语法错误，这点确实是硬伤
|
 |
19
subpo 2013 年 2 月 27 日
这是啥网站，看起来很有意思
|
|
20
RisingV 2013 年 2 月 27 日
it seems that go does the right thing and does it right...
|
 |
21
ccming 2013 年 2 月 27 日 1
这个世界早晚是 Ruby 的
|
|
22
clino 2013 年 2 月 27 日
@RisingV python的语法错误完全可以在编写的时候检查
应该说是动态语言和静态语言在静态类型检查上的不同,这个跟是否解释型语言没关系,只是因为解释型语言大多是动态语言 而动态类型可不一定是短处,本身是会带来很多好处的 |
 |
23
lookhi 2013 年 2 月 27 日
我觉得吧python不错。至少我们的网站就是用python做出来的，能达成需求就好。
|
 |
24
Mac 2013 年 2 月 27 日
这货用xampp搭的肉鸡网站吧？
|
 |
25
daweiba 2013 年 2 月 27 日
「听好儿子，要提出目标，但不可盲目追随它」
「我明白了爸爸，就像Python那样提出『只采用唯一正确的方法』那样的目标，实际上却存在2、3版本的不兼容」 「住口！」 「urllib和urllib2」 「住口！！！」 |
 |
26
soulhacker 2013 年 2 月 27 日
C/C++ Java 这些静态编译型语言确实有的一大优势是高度优化的编译和静态代码检查，前面有朋友引用 Guido van Rossum 的话说「靠编译器找错误是不对的」，这说法不完全赞同，好的编译器和静态、动态代码检查确实能够极大的提升开发效率，尤其是比较大型的项目，测试驱动并不是万灵药，本身效率也不是那么的高。
当然万事有得必有失，他们也缺乏现代动态语言的很多优势，这是要辩证去看的。 |
 |
28
est 2013 年 2 月 27 日
python这个强类型语言被黑出翔了。。。。
|
 |
29
lecher 2013 年 2 月 27 日
Dr. cai 貌似就是蔡万钊，在很多社区都是实名注册的。比如chinaunix
http://bbs.chinaunix.net/home.php?mod=space&uid=23924138&do=thread&type=reply&view=me&from=space 目前Dr.cai 维护着几个C++的项目这是他的github：https://github.com/microcai/ 这是他的blog： http://microcai.org/ 神奇的是此人chinaunix的自我介绍是本科退学，学历又是博士 |
 |
30
tangzx 2013 年 2 月 27 日
看了网站的第一感觉，被几行闪闪发光的红字亮瞎了眼
|
 |
31
reorx 2013 年 2 月 27 日 1
 just a troll.. |
|
32
RisingV 2013 年 2 月 27 日
@clino 和动态静态没有关系，我说的是部分解释型语言的缺点，比如shell，函数声明都必须在前面。纯粹逐行解释，没有全文遍历的解释型语言都会有这个问题。但，但凡动态语言，基本都是解释型的，js、python之类的解释型语言通过词法分析和语法分析得到语法树后，就可以开始解释执行，语义上的错误必须在运行期才能发现。所以真正的错误运行了才知道。如果没有足够的测试用例覆盖所有的代码，其可靠性比静态语言真差远了。
|
|
33
RisingV 2013 年 2 月 27 日
大拿说的话，听了就当真理。也不搞清楚人家什么意思，显而易见的错误当然由编译器抵下了，业务逻辑上的bug，自然不能依赖编译器。
|
 |
35
dreampuf 2013 年 2 月 27 日
http://microcai.org/2012/12/25/whypythonbad.html
并发，脚本解释类型带来的开发环境问题 这两个问题虽然老生常谈，不过因时而异，可以继续讨论。 编译检查，1000行，开发效率不行，执行效率也不行。。。其他主观（发行版强推，玩具，。。。） 这些就可以当作放屁了 总之给我的感觉是非科班出身，随便鼓捣玩玩，不求甚解，广度有余深度不足。浮躁。 |
|
36
clino 2013 年 2 月 27 日
@RisingV 动态语言不一定是解释型语言,python可以说是编译型语言而不是解释型的,因为基本上都是编译成字节码(文件上看是pyc或pyo)以后再执行的,是解释型还是编译型在这里不是重点
"没有全文遍历的解释型语言都会有这个问题"python当然可以完整分析完所有的源文件,所有语法错误完全没问题.但关键是在动态,里面的很多东西在运行期才能知道的,很多java/c/c++在解析完文件以后能确定的东西对于动态语言是无法确定的. |
 |
38
zuroc 2013 年 2 月 28 日
|
 |
39
monkeylyf 2013 年 2 月 28 日
唉 又一轮的online masturbaxxxx.
|
 |
40
cicku 2013 年 2 月 28 日
microcai 又被喷了。。啊哈哈哈、、
我们邮件列表的。 以前听说在新浪。 |
 |
41
lyric 2013 年 2 月 28 日 via Android 1
此人是中文开源社区的大喷子
|
 |
42
workaholic 2013 年 2 月 28 日
有意思么，高手根本不在乎用什么语言
|
 |
43
BOYPT 2013 年 2 月 28 日
呵呵
|
|
44
clino 2013 年 2 月 28 日
|
 |
45
rorvn 2013 年 2 月 28 日
这货是中文linux圈的一朵奇葩，在#ubuntu-cn偶尔会遇到
|
 |
46
FrankHB 2013 年 2 月 28 日
编译/解释型是对语言实现而言的，对语言分类本来就是扯蛋的（因为通常使用的实现形式的）偷懒说法。
想想Lisp是编译还是解释型的？C的实现就一定要有编译器？ |
 |
47
aisk 2013 年 2 月 28 日
@RisingV 非常不认同你的观点，jit和是否编译没有直接关联，上面说了js就是个例子。本来语言就没办法说是否编译/非编译，还得看具体实现了，Java还有GCJ这个AOT编译器呢，C还有很多人写解释器呢。
就算从具体实现看，那编译到字节码然后解释执行算编译还是解释？全程jit执行又算什么？ |
|
50
cicku 2013 年 2 月 28 日
|
 |
51
matz 2013 年 2 月 28 日
对于Python和Ruby来说，我都觉得差不多。。。
|
|
52
RisingV 2013 年 2 月 28 日
|
|
53
RisingV 2013 年 2 月 28 日
@workaholic 我认为高手最在乎用什么语言，不同语言之间简直就是不同的宗教，为信仰而言。用热衷函数语言的和热衷OO的几乎是两个世界的人
|
|
54
keakon 2013 年 2 月 28 日
|
|
55
RisingV 2013 年 2 月 28 日
@keakon 文章见解倒蛮独到的，一直很反感GB系列的编码，没想到还有其自身优势。但是从非技术层面来说，unicode以及得到推广，用起来比较方便，为了省几个字节而用中国国标，老外肯定不答应。
|
|
57
RisingV 2013 年 2 月 28 日
@aisk gcj诞生于openjdk诞生之前，人们希望有一个开源的选择。如今用得不多了吧。我试用过，执行不一定比jre快，更多时候还要慢。
刚才已经说了，语言规范是脱离于实现的，但是还是会按照主流使用方式和惯例，把XX语言说成编译型，把XX语言说成是解释型，这样比较有实际的参考价值。 |
|
58
aisk 2013 年 2 月 28 日
@RisingV 那遇到没主流使用和习惯的语言怎么分类呢？比如lisp系的各种方言？Scheme常用的几个，Guile是字节码+jit，chicken是编译到c->再到机器码，这又怎么算呢？
我还是觉得，脱离实现讨论语言是耍流氓。 |
|
59
RisingV 2013 年 2 月 28 日
@aisk 那你就认为我是耍流氓把。这些叫法确实都是convention或者tradition，而不是一个truth。LISP的情况在习惯中确实没有被划分到任何一种，那么这就是它的convention，遵循它就是了。
|
|
62
clino 2013 年 2 月 28 日
@RisingV "理论上是不存在编译和解释的分类，两者皆可实现" 服了,是你一直在用解释型语言来说python的缺点,我指出你的理解错误,然后你又来个理论上不存在
具体对于某个实现例如cpython,当然可以用这个分类来分了 |
|
63
RisingV 2013 年 2 月 28 日
@clino 这句话完全成立，主要也是和aisk同学说的。具体实现当然有分类，这是废话。但谈论语言(本身只是一套规范)的分类不一定有结果，因为不一定只有一种类型的实现，怎么叫只是因为惯例，就这么简单。仔细看一下前文，我只是说部分解释型语言（如果你一定要咬文嚼字的话，就是部分语言的解释型实现）的缺点。我对python不够了解(也没兴趣)，通过DR.蔡 的这番论述，以为它也有这个缺点，这点你已经说清楚。我对python没有好恶，你也不必护主心切了
|
|
64
clino 2013 年 2 月 28 日
@RisingV 以我的了解其实现在的动态类型语言的实现基本上都采用编译型甚至用上jit了,纯粹解释型的应该是很少.对python的缺点我是很清楚的,我之前写的这些完全扯不上护主,不要因为我指出你的理解错误难堪而乱讲话.
|
|
65
RisingV 2013 年 2 月 28 日
@clino 这个所谓的“理解错误”是你一厢情愿的，我承认的是我以为python有shell那样的缺点，那是因为我对它确实不了解。至于你扯解释和动态语言的关系，真的都是你一厢情愿。不妨看一下聊天记录。
|
 |
66
dexter 2013 年 2 月 28 日
对！！！
无限支持python是烂语言 lol |
|
68
workaholic 2013 年 2 月 28 日
@RisingV 我并没有否认各个语言之间的差异，同样是用一个差的语言，高手也能编出nb的程序，就看你水平了，只有“半瓶醋”才讨论哪个语言好哪个不好
|
|
69
RisingV 2013 年 2 月 28 日
@workaholic
最初接触编程的时候我的想法和你是一样的。好比武学的“无招胜有招”，听上去不错，好比世界大同的美好愿望，看上去美好，但实际却不现实。 聪明人不会干费劲不讨好的事情，高手有能力去驾驭任何语言，但不代表他有必要去用一门拙劣的语言干NB的事情。事实是，那样不NB，反而显得很不明智。 很多linux kernel党就都不怎么喜欢C++（我没有贬低C++的意思），就是个例子。 你可以看看《黑客与画家》，看看保罗•格雷厄姆对编程语言的观点。 |
|
70
workaholic 2013 年 2 月 28 日
@RisingV 这和世界大同怎么能搞到一起去，高手就是高手，编程语言都是他们设计出来的。你回去好好看看，第14章标题下面写着“一种好的编程语言，是让黑客可以随心所欲使用的语言”，你是在帮我证明我的观点
|
|
71
workaholic 2013 年 2 月 28 日
@raincious ^_^
|
|
72
RisingV 2013 年 2 月 28 日
@workaholic 你真的理解我说什么了吗？你真的看那本书了吗？雷死我了。和你讨论这个就是我的错误
|
|
73
workaholic 2013 年 2 月 28 日
@RisingV ......没看过的话和你在这墨迹有意思么，希望你再看看
|
 |
74
myrual 2013 年 3 月 1 日 via iPhone
哇，有空吵架不如赶紧多删除几行无用代码节省宝贵的硬盘空间
|
|
75
FrankHB 2013 年 3 月 3 日
@workaholic 似乎你在说Paul Graham是半瓶醋？
|
 |
76
asstar 2013 年 3 月 8 日
pypy不是也有jit么。还有ironpy和jython等实现，以编译论语言者其实没多大意思。而且现在大部分动态语言都是先编译成opcode的。
动态语言本来带来的是开发效率，如果非要和c/c++比性能，那就没意思了。如果真有开发效率和性能都高过c/c++的动态语言，那还有c/c++存在的价值么？ |
 |
77
shiran 2013 年 3 月 9 日
这是什么网站啊？
|
 |
78
venglide 2013 年 3 月 10 日
挺欢乐，感觉说得还是有一定道理的，至少有自己的见解。现在最多的就是看到有这样的帖子，底下就会出现一群疯狗，王垠的最新文章就是个例子。可喜的是，v2ex上的人偏相对理性~
|
Select Language