我觉得Python很好，就是语法层面本身像是个半成品
1. 缩进这个特色，是最被诟病的，实际上，写代码的人，往往都会主动缩进的，写C++, Java的人，哪个不缩进啊？根本不需要你强制。
结果造成现在天天有人纠结 空格和Tab的问题。

2. Main，python提供了一个类似于C语言main function的东西，那是个神马东西？？

3. 构造函数，__init__， 在C语言里面 __XXXX__都是系统保留，往往是不太希望程序员大量用的东西，
而且Python里面使用这种风格的__XXX__的东西还不少呢，


4. 成员方法第一个参数，自己写self。感觉山寨得要死。【不要跟我讲为什么要这样设计，你应该看看为什么Ruby避免了这样的设计】


5. if, for, def, class之后的那个冒号，是多余的。

从我做词法分析的经验看，这哥们当初这么搞的时候，就是为了自己方便，分析起来比较简单。

Ruby的语法描述文件，上万行，Python的语法文件，几百行，好意思吗？

吐槽有分，吐我没分~
[解决办法]
哎 我一个作C/C++开发通信协议的人被临时借到其他部门做起了WEB开发维护, 用到的就是python.
不论python被夸的多么美,我都不喜欢它.
虽然这门语言确实简单,容易上手. 用了一个星期,就在没有任何人指导的情况下搞通了 phthon + django + apache 的WEB架构.
现在除了实际开发工作, 我基本不去碰它.

为了接分,把我实际遇到几点对python的不满吐槽下:
1. 变量使用无需类型, 特别是函数中, 甚至可以用于多种不同的类型, 如果参数名字定义不够明显的实际意义,那你就去猜吧. 这个不就和C++模板有的异曲同工之处了么? 但是不然, 因为没有严格类型, 各种集成环境都不能很好的提供各种函数调用被调用的关系. 在我维护的WEB框架里, 前任代码写的天马行空, 全无注释, 多个文件十层以上的函数调用跳转让我初期代码看的头痛欲裂. 深为痛恨.

2. 内存占用问题, 特别对上django的数据库模型机制, 所有访问的表全放在内存中, 一个外连接的访问直接把外连接表中数据全部搞到内存中.
且类java的内存管理机制, 回收内存仅回归本程序所用, 典型的占着茅坑不拉屎, 不管别人多么急切.
在关系复杂的数据库下,执行大量数据简直灾难. 我已无力处理批量数据的内存不足问题.

[解决办法]
1. 缩进这种问题习惯了就好, 如果为 TAB 和 空格 困扰, 那是你没有找到一个好的编辑器.
2. 不存在这个东西. 只是每一个 py 文件运行的时候, 如果他是作为模块被 import 的, 那么有个隐藏的 __name__ 变量, 值是模块的名字. 如果这个 py 文件直接被命令行启动, 那么 __name__ 的值就是 "__main__"
3. __ 的名字在 Python 里也是属于系统定义的东西, 自己命名的时候最好别这样命名.
4. 这个是语言设计的哲学问题. 设计的 Python 的人认为, 既然函数里有这个参数, 为什么要做成隐藏的, 然后去定义那么多的潜规则呢? 直接明确给出来, 少一些潜规则.
5. 多余的东西多了, 关键是把这些东西省掉的话, 对人来说它是否还是明确的.

Python 的哲学是 “优雅”、“明确”、“简单”, 一个上万行的语法描述显然不符合 Python 的哲学. 进入 Python 命令行, 用 import this 来看看 Python 的设计原则吧:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.

If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

了解了这些原则, 你就能理解语言的设计者为什么要那样设计了.
[解决办法]
严重同意楼主观点！
参考http://bbs.csdn.net/topics/380157851
[解决办法]
强制缩进的确比较奇怪。。
[解决办法]
最喜欢的就是缩进，不管是space还是tab。
而强制缩进保证了代码的整齐，就像能编译过的C，吾等整洁控的最爱

# python's main
if __name__ == "__main__":

# ruby's main
if __FILE__ == $0
end

[解决办法]
不懂python 纯粹路过
[解决办法]
汗。。。近期正打算学学python呢，据说openstack就是用python写的