[转]Python Is Not Java

原文：

I was recently looking at the source of a wxPython-based GUI application, about 45.5KLOC in size, not counting the libraries used (e.g. Twisted). The code was written by Java developers who are relatively new to Python, and it suffers from some performance issues (like a 30-second startup time). In examining the code, I found that they had done lots of things that make sense in Java, but which suck terribly in Python. Not because "Python is slower than Java", but because there are easier ways to accomplish the same goals in Python, that wouldn't even be possible in Java.

So, the sad thing is that these poor folks worked much, much harder than they needed to, in order to produce much more code than they needed to write, that then performs much more slowly than the equivalent idiomatic Python would. Some examples:

A static method in Java does not translate to a Python classmethod. Oh sure, it results in more or less the same effect, but the goal of a classmethod is actually to do something that's usually not even possible in Java (like inheriting a non-default constructor). The idiomatic translation of a Java static method is usually a module-level function, not a classmethod or staticmethod. (And static final fields should translate to module-level constants.)

This isn't much of a performance issue, but a Python programmer who has to work with Java-idiom code like this will be rather irritated by typing Foo.Foo.someMethod when it should just be Foo.someFunction. But do note that calling a classmethod involves an additional memory allocation that calling a staticmethod or function does not.

Oh, and all those Foo.Bar.Baz attribute chains don't come for free, either. In Java, those dotted names are looked up by the compiler, so at runtime it really doesn't matter how many of them you have. In Python, the lookups occur at runtime, so each dot counts. (Remember that in Python, "Flat is better than nested", although it's more related to "Readability counts" and "Simple is better than complex," than to being about performance.)

Got a switch statement? The Python translation is a hash table, not a bunch of if-then statments. Got a bunch of if-then's that wouldn't be a switch statement in Java because strings are involved? It's still a hash table. The CPython dictionary implementation uses one of the most highly-tuned hashtable implementations in the known universe. No code that you write yourself is going to work better, unless you're the genetically-enhanced love child of Guido, Tim Peters, and Raymond Hettinger.

XML is not the answer. It is not even the question. To paraphrase Jamie Zawinski on regular expressions, "Some people, when confronted with a problem, think "I know, I'll use XML." Now they have two problems."

This is a different situation than in Java, because compared to Java code, XML is agile and flexible. Compared to Python code, XML is a boat anchor, a ball and chain. In Python, XML is something you use for interoperability, not your core functionality, because you simply don't need it for that. In Java, XML can be your savior because it lets you implement domain-specific languages and increase the flexibility of your application "without coding". In Java, avoiding coding is an advantage because coding means recompiling. But in Python, more often than not, code is easier to write than XML. And Python can process code much, much faster than your code can process XML. (Not only that, but you have to write the XML processing code, whereas Python itself is already written for you.)

If you are a Java programmer, do not trust your instincts regarding whether you should use XML as part of your core application in Python. If you're not implementing an existing XML standard for interoperability reasons, creating some kind of import/export format, or creating some kind of XML editor or processing tool, then Just Don't Do It. At all. Ever. Not even just this once. Don't even think about it. Drop that schema and put your hands in the air, now! If your application or platform will be used by Python developers, they will only thank you for not adding the burden of using XML to their workload.

(The only exception to this is if your target audience really really needs XML for some strange reason. Like, they refuse to learn Python and will only pay you if you use XML, or if you plan to give them a nice GUI for editing the XML, and the GUI in question is something that somebody else wrote for editing XML and you get to use it for free. There are also other, very rare, architectural reasons to need XML. Trust me, they don't apply to your app. If in doubt, explain your use case for XML to an experienced Python developer. Or, if you have a thick skin and don't mind being laughed at, try explaining to a Lisp programmer why your application needs XML!)

Getters and setters are evil. Evil, evil, I say! Python objects are not Java beans. Do not write getters and setters. This is what the 'property' built-in is for. And do not take that to mean that you should write getters and setters, and then wrap them in 'property'. That means that until you prove that you need anything more than a simple attribute access, don't write getters and setters. They are a waste of CPU time, but more important, they are a waste of programmer time. Not just for the people writing the code and tests, but for the people who have to read and understand them as well.

In Java, you have to use getters and setters because using public fields gives you no opportunity to go back and change your mind later to using getters and setters. So in Java, you might as well get the chore out of the way up front. In Python, this is silly, because you can start with a normal attribute and change your mind at any time, without affecting any clients of the class. So, don't write getters and setters.

Code duplication is quite often a necessary evil in Java, where you must often write the same method over and over with minor variations (usually because of static typing constraints). It is not necessary or desirable to do this in Python (except in certain rare cases of inlining a few performance-critical functions). If you find yourself writing the same function over and over again with minor variations, it's time to learn about closures. They're really not that scary.

Here's what you do. You write a function that contains a function. The inner function is a template for the functions that you're writing over and over again, but with variables in it for all the things that vary from one case of the function to the next. The outer function takes parameters that have the same names as those variables, and returns the inner function. Then, every place where you'd otherwise be writing yet another function, simply call the outer function, and assign the return value to the name you want the "duplicated" function to appear. Now, if you need to change how the pattern works, you only have to change it in one place: the template.

In the application/platform I looked at, just one highly trivial application of this technique could have cut out hundreds of lines of deadweight code. Actually, since the particular boilerplate has to be used by developers developing plugins for the platform, it will save many, many more hundreds of lines of third-party developer code, while simplifying what those developers have to learn.

This is only the tip of the iceberg for Java->Python mindset migration, and about all I can get into right now without delving into an application's specifics. Essentially, if you've been using Java for a while and are new to Python, do not trust your instincts. Your instincts are tuned to Java, not Python. Take a step back, and above all, stop writing so much code.

To do this, become more demanding of Python. Pretend that Python is a magic wand that will miraculously do whatever you want without you needing to lifting a finger. Ask, "how does Python already solve my problem?" and "What Python language feature most resembles my problem?" You will be absolutely astonished at how often it happens that thing you need is already there in some form. In fact, this phenomenon is so common, even among experienced Python programmers, that the Python community has a name for it. We call it "Guido's time machine", because sometimes it seems as though that's the only way he could've known what we needed, before we knew it ourselves.

So, if you don't feel like you're at least ten times more productive with Python than Java, chances are good that you've been forgetting to use the time machine! (And if you miss your Java IDE, consider the possibility that it's because your Python program is much more complex than it needs to be.)


译：

最近我一直在看一个基于wxPython的GUI应用程序代码，大概45.5KLOC的左右，而且这还不包括它所用到的库(如Twisted)。代码是由那些对Python比较生疏的Java的开发者写的，所以它存在很严重的性能问题(如三十秒的启动时间)。在检查代码的时候，我发现他们写了很多在Java中能讲得通但是对Python来说去却是很难接受的东西。并不是因为“Python比Java慢”，而是因为在Python中有更方便的方法去完成同样的目标，甚至是在Java中不可能的事情。
所以，令人难过的事就是这些家伙事倍功半，写的那些代码比本应合乎用Python语言实现的慢很多。下面，让我们来看一些例子：

Java中的静态方法不能翻译成Python的类方法。哦，当然，他多多少少也能产生同样的效果，但类方法的目的实际上是做一些通常在Java中甚至都不可能的事情(如继承一个非默认的默认函数)。Java静态方法惯用的翻译通常翻译成一个模块级的函数，而不是一个类方法或静态方法。(并且静态常量应该翻译成模块级常量.)
这不是性能上的问题，但是一个Python程序员如果想调用Foo.someMethod，他要是被迫采用像Java中Foo.Foo.someMethod的方式去做的话，那么他就会被逼疯的。有一点一定要注意:调用一个类方法需要一个额外的存储空间,而调用静态方法或函数就不需要这样.
对了,还有就是这些Foo.Bar.Baz的属性链也不是自己就能数出来的.在Java中,这些带点的名称是有编译器来查找的,运行的时候并不会去考虑一共有多少.而在Python中,查找的过程是在运行时进行的,所以要包括每个点.(在Python中,要记住一点,"平铺的结构比嵌套的要好",尽管相对于从性能方面来说,可能它更多涉及的是"可读性"和"简单要比复杂好".)

要使用switch语句吗?Python翻译将是一个哈希表，不是一堆if-then语句。要使用在Java中不是switch语句而且还有字符串参与了的一堆if-then语句吗?它将仍然是一个哈希表。Python字典是用在我们所了解的领域中认为是最佳性能之一的哈希表来实现的。你自己所写的代码也不会比这个再好了，除非你是Guido、Tim Peters和Raymond Hettinger的私生子,而且还是遗传增强了的。

XML不是答案。它也不是一个问题。现在用正则表达式来解释Jamie Zawinski，“一些人，当他遇到一个问题的时候，就会想‘我知道，我要用XML.’那么他们就有两个问题了。”
相对于在Java中来说这是个不同的情况，因为比起Java代码，XML是灵活而且有弹性的。但比起Python的代码来，XML就是一个船锚，一个累赘。在Python中，XML是用来协同工作的，而不是你的核心功能，因为你不需要那么做。在Java中，XML可能是你的救世主,因为它让你实现了特定领域的语言并且“不用编码”就提高你的应用程序的适应性。在Java中，避免编码是一个很大的优势，因为编码意味着重新编译。但在Python中，通常是，写代码比写XML更简单。还有就是Python处理代码要比处理XML快很多很多。(不仅仅是这个，你必须写XML处理代码，同时Python就已经为你写好了.)
如果你是一个Java程序员，你并不能利用本能知觉来考虑你是否要在你的Python核心应用中使用XML作为一部分。如果你不是因为信息交互的原因去实现一个已经存在的XML标准或是建立某种输入、输出格式或者建立某种XML编辑器或处理工具，那么就不要这么做。根本不要去这么做。甚至连想都不要想。现在，丢掉那个XML模式然后把你的手解放出来吧！如果你的应用程序或者平台要被Python开发者使用，他们只会感谢你不要在他们的工作中添加使用XML的负担。
这里唯一的例外是如果你的客户(your target audience)确确实实因为某些原因而需要使用XML。就好像，他们拒绝学习Python但如果你使用XML他们就给你付钱，或者你打算给他们一个很棒的能编辑XML的GUI，还有就是这个XML的GUI是另一个人写的，同时你得到免费使用的权利。还有一些很少见的架构上的原因需要用到XML。相信我，它们不会应用到你的程序中去的。如果有疑问，对一个资深的Python开发员解释你的用例。或者，如果你脸皮厚而且不介意被人嘲笑的话，试试向一个Lisp程序解释你的程序为什么要用XML!

Getter和setter是恶魔。我应该说它是恶魔,是魔鬼！Python对象不是Java Bean。不要写什么getter和setter，而是还把它们内置在“属性”里面。它直到你能证明你需要比一个简单访问复杂一点的功能时才有意义，要不然，不要写getter和setter。它们是CPU时间的浪费，更要紧的是，它们还是程序员宝贵时间的浪费。不仅仅对于写代码和测试的人，对于那些要阅读和理解它们的人也是。
在Java中，你必须使用getter和setter,因为公共字段不允许你以后改变想法再去使用getter和setter。所以,在Java中你最好事先避开这些"家务杂事".在Python中，这样做很傻，因为你可以以一个普通特性开始并可以在任何时间改变你的想法，而不用影响到这个类的任何客户。所以不要写getter和setter方法。

代码重复在Java中通常来说就是一场不可避免的灾祸，你必须经常反复地写同一个方法而只有一点点的变化(通常是这是因为静态类型约束)。在Python中这样做是没有必要的也是不值得的(除了极少数一些特定的场合需要内联一些要求性能的函数)。如果你发现自己一遍一遍在写同样的代码而且变化很少，你就需要去学一下闭包。他们实际不并是那么可怕。
这就是你要做的。你写了一个包含了函数的函数。这里内部的函数就是你要一遍遍写的函数的模版，但是在里面加入了针对不同情况的函数要使用变量。外部的函数需要刚刚提高的那种变量作为参数，并且将内部的函数作为结果返回。然后，每次你要写另一种略微不同的函数的时候，你只要调用这个外部的函数，并且把返回值赋给你要让“重复”函数出现的名字。现在，如果你需要改变这个工作方式，你只需要改变一个地方：这个模版。
在我所看过的应用程序/平台中，只有一个很微不足道的程序使用了这个技术,它去掉了数百行重负的代码。实际上，因为开发者使用了特别的样板文件来为这个平台开发插件，所以这会节省很多很多第三方开发人员的代码，同时也使那些程序员要学习的东西变得简单了。

这只是Java->Python思维方式转变的冰山一角而已，现在我能正确的转变而不用去钻研程序的细节。本质上，如果你曾经用过一段时间Java，而且对Python比较陌生，那么你不要太相信自己的本能。你的本能已经被Java调节，而不是Python。向后退一步来说，最重要的是不要再写这么多代码了。
为了这样做，让自己觉得更加需要Python。假装好像Python是可以做任何你想做的魔棒，而你无须出一点力。问一下，“Python怎样解决我的问题？”还有“Python语言的哪个特点和我的问题最相似？”如果对于你需要的东西其实已经有了某种固定形式,那么你绝对会感到惊讶的。事实上，这种现象实在是太普遍了，甚至即使在很有经验的Python程序员中也会出现，以至于Python社区中给这种现象起了个名字。我们称之为“GUIDO的时间机器”，因为在我们自己还没有掌握它之前,通常看上去要得到我们所需要的东西好像那是唯一的方法。

所以，如果你在使用Python时候不能感到比使用Java要至少多出10倍的生产力话，你就最好做一下改动,你是不是忘记使用time machine!(chances are good that you've been forgetting to use the time machine)(同时如果你还怀念你的Java IDE，你可以这样想：因为你写的Python程序比他所需要的要复杂得多.)

译者注：Phillip J. Eby的blog在国外软件开发领域影响很大，广为流传的两篇文章是：“Python Is Not Java”与“Java is not Python, either...”，我会陆续为大家奉上。Phillip J. Eby还是一位多面手，除了在Python上的深厚造诣外，在心理学研究上也颇有建树，著作有《You, Version 2.0》。

注：
原文的链接：http://dirtsimple.org/2004/12/python-is-not-java.html
翻译来自CSDN，链接：http://blog.csdn.net/pjeby/archive/2006/08/06/1028334.aspx