The language in which you program and its interpreters or compilers are only some of the tools you use to develop software. Another important matter is your programming environment. Unlike some languages, where your choices are limited, such as Delphi or the .NET languages, where there are one or two obviously superior options, Python has no “standard” tool; Python developers use any of a wide array of editors and IDEs. Choosing the right tool for you is not difficult, but it is not to be taken lightly: you get the best out of any of these tools by deeply learning their features, so it’s best if you make a good choice up front to avoid wasted effort.
Both in person and on discussion sites, when someone asks what IDE is best for Python, there will be two categories of response: one is to suggest your favorite Python IDE, and the other is to point out that IDEs offer little for Python programming — or in more extreme cases, programming in general. I admit my preconceptions: I fall into the latter camp. I use Emacs for almost anything that can be represented as text, and I find it productive and flexible. I will try to put aside my bias, however, and discuss the thing impartially.
There are languages where you’ll find broad agreement among developers that an IDE is a necessity: Java, Delphi, C# and VB.NET are clear examples of this. One characteristic all these languages share is that there’s a fair amount of stock code, which is necessary for the compiler but not semantically meaningful for your application and which must be in place; in Java and C#, you have to define a class before you can even call a function, and in Delphi, you have to define a function’s interface in one place and implement the logic elsewhere. IDEs are great for this; they generate all of the boilerplate code for you.
Python (like Perl, Go, Ruby, and Lisp, among others) is different. There’s less boilerplate; almost every character you type is directly expressive of the functionality you are trying to create. There’s less low-hanging IDE fruit, you could say. That makes IDE usage a more debatable proposition, and that’s supported by the division among Python programmers on this issue.
The obvious advantage of an IDE is that it does a lot of work for you. Sure, many text editors can be configured to do so as well, but an IDE saves you the trouble. Ideally, you should be more productive with an IDE than a simple (or not-so-simple) text editor. So why would anyone continue to resist IDEs?
An issue many developers raise in favor of text editors is that over-reliance on IDEs prevents their users from deeply learning their language. There’s some truth to this; if you rely on auto-completion to remind you of function, class, and method names, there is a danger that you will never learn them; and for many reasonably fast typists, myself included, typing a name you know is faster than using auto-completion. The same goes for snippets: if you always insert, say, class definitions using snippets, you might never learn the syntax for yourself.
Of course, if you always have your IDE, it’s not necessarily a problem, is it? Well, maybe. In one sense, the more functionality an IDE offers, up to a certain point, the more constraining it is, because once an IDE is solving your coding problems for you, it has a tendency to restrict your choice of solutions to those provided by your IDE. To the extent that that is true, your IDE may lead you to choose less-than-ideal development paths simply because it works so well.
That being said, many Python programmers use IDEs, and many don’t, and they’re all productive and happy with their choice. It seems to me that if you’re happy with your favorite text editor, you are probably better off using it. If you’re an IDE person already, you know what you want; look at the IDEs. But if you’re on the fence, how should you choose? I think a good indicator is how you use programs right now. Do you type quickly? Are you a keyboard-shortcut junkie? Do you view it as a failure every time you touch your mouse? Then you’d probably be happier if you use a text editor, especially a highly-customizable one like Emacs or Sublime Text. If, on the other hand. you are a mouser, you are likely to prefer an IDE.
Another good point to consider is your use of programming languages in general; if you expect Python to be your main language, with little use of others, or you expect to use Python as your only non-IDE-bound language, an IDE is probably a good idea; you’ll get good at using it and it will be an effective tool for Python. On the other hand, if you (like me) are a language gourmand, who consumes languages like General Tso’s chicken, you’ll probably want to use a text editor; you can become very fluent with one editor, and the skill you develop with it will make you more productive in all your languages, though you may not be using the most convenient tool for any specific one.
Finally, if you’re just beginning Python, let me put in a plug for simple editors: it’s best for you to learn the language and its libraries well writing it all yourself, and then if you think an IDE would speed your work along, use it. You’ll find that you learn the language faster and more completely if you take this route.
A note: I’ve limited our selection to cross-platform editors and IDEs, because Python is a cross-platform language, and no matter how much you love your current operating system, you’re likely to find yourself working on a different one at some point or other, and you’ll want to have your familiar tools. Besides, there are so many good cross-platform options, it’s foolish to limit yourself to a single-platform tool. All of the options listed run on Windows, Linux, and Mac OS X, and some run on a surprising number of others.
Also, I’m considering this topic from the point of view of an early-stage Python programmer. With that in mind, I’ve done little in the way of customization, except in highly-customizable editors such as Emacs, Vim, and Sublime Text. This is especially the case with IDEs; I’ve taken the position that if a tool is supposed to be dedicated to Python, and does everything, it ought to do it out of the box, so I’ve tested IDEs mostly in the state that basic installation instructions create. If that seems unfair to you, bear it in mind as a source of perceived bias.
We’ll begin with editors.