In the middle of his essay about why getters and setters are evil, Ryan Tomakyo took a swipe at IDE's:

In Java, the tool (IDE) is the brush and the code is the canvas. In Python, the language is the brush and the machine is the canvas - the language and the tool are the same thing. In Java you enhance the IDE, in Python you enhance the language.

This is the primary reason why there is little serious demand for Python IDEs. Many people coming to Python can't believe no one uses IDEs. The automatic assumption is that Python is for old grey beards who are comfortable with vi and Emacs and refuse to accept breakthroughs in programming productivity like IDEs. Then they write a little Python code and realize that an IDE would just get in their way.

Actually, I think that the real grey beards here would be the folks that came from Lisp Machines or Smalltalk. These languages are like Python -- if you want to enhance the language, you can. In fact in Lisp, you even have support in the language for metalinguistic abstraction. Even so, the inventors of the Lisp Machine and the Smalltalk environment did not eschew powerful tools simply because they had languages for stratified design.

Notice that I did not say IDE. IDE has become one of those words like "apple pie", except instead of meaning goodness, it means badness. What I am interested in are tools that work on the deep structure of code, as Jon Udell recently wrote. I want to have tools that understand what a program means, not merely its textual representation. I'm definitely an Emacs partisan -- I've been using GNU Emacs since version 17 and I used the Gosling Emacs on BSD 4.1 before that. I've hacked the keybindings on OS X to include a large number of keys. But I would sorely love to get off of Emacs for programming, because Emacs doesn't really understand what a program means. (Yes, I know, there's elisp, so I could make Emacs understand what my program means -- an elisp is one of the reasons that I continue to use emacs -- I can mould its behavior to match my preferences).

When I do Java, I do Eclipse, although before that I was an Emacs and Java on the command line kind of guy. It was only when I could get refactoring, and the ability to see all the callers of a method that I was finally pushed over the edge. The Eclipse guys are still at the beginning of what they could do with the information that they have about Java programs. Imagine a rendering of source code that just doesn't display the type declarations. That would be one way to solve the "type declarations are annoyingly in my face problem". Just treat the source code presentation as a view on the static structure of the program and allow multiple presentations. In one presentation, you see regular Java. In another presentation you see Java without the declarations.

With Python, the tools are different. Right now I use a combination of Emacs and ipython for much of my work. When I start having to interact with code in the application layer of Chandler, then I find it useful to have Wing in order to present a usable debugger interface (I can hear James Robertson cringing all the way from the other side of the country). But none of these tools really understand what a Python program means either.

Having a good language doesn't mean that you won't get more leverage from good tools.