Frankly, as a developer who has tried a number of IDE's and text editors, I'm not sold on the idea that your choice of editing environment has any correlation to any of those titular descriptors in the first place.
I always use IDE to refactor code, as other developers might not writing clean code, even myself.
Deleted comment
But there's no substitute for an autopep8 [1] commit script. (Preferably make it a check, not a direct reformat)
Good design will give you a lot cleaner professional maintainable code.
I do databases, but I like Linus's quite about getting the data structures right, and not needing to worry about the code. I find if the application level is getting too complex, it probably means the database design isn't matching the problem correctly. Others on my team would keep adding "if" statements to the forming ball of mud. (Usually) I find it easier to take the pain of a schema migration up front. The code then becomes simpler, more reliable, and I can usually forget about it.
As for the text editor comment. In general no, but I know a lot of poor programmers who are too lazy to set up / learn an IDE (or any other way of using a step through debugger).
And specifically, it's a lot harder than doing it in java or C++. I've seen C++ codebases that exceed 8 million lines of code and held together (not without friction, that I guarantee). I've seen java codebases with about half that that held together a lot better than the C++ ones.
Even accounting for the fact that python easily lets you achieve 5 times as much in the same amount of lines (at the cost, imho, of more surprises when wrong types get passed to your functions). I'm not sure "normal python" is more than a little bit more succint than (good) C++ though. Easier to read, sure, if you're allowed to make assumptions about types. But not that much shorter.
I've yet to see the first million line python codebase. And python has certainly had sufficient time to develop such codebases. Why aren't they here already ? Those C++ codebases were almost operating systems though (with extremely tricky threading support libraries, every project it's own of course), something you fundamentally can't do in python. The java codebases were financial stuff though, something that could easily be done in python, and they certainly have the money to absorb the increased hardware cost, and looking to have faster development turnaround. That's another discussion I can guarantee you will have with your boss if your app really grows, the hardware cost. When it comes right down to it, a programmer is worth (rule of thumb) about 15 servers. If python means one less programmer, but 50 extra servers, you will lose that discussion with your boss.
Dynamic typing is certainly a massive advantage for small codebases. It becomes more and more of a disaster on larger ones though. So an IDE for python ... it merely lets you lose the battle with your code that much faster.
One of the main benefits of using Python for me, is that there is usually a (decent quality) library written. If you are having to re-implement everything from scratch and are not including the libraries.
The last thing close to a million lines of code I worked on was horrendous. Legacy banking app in VB6 (after MS had stopped support). I would write a method to do something, then a month later I would find another method somewhere else in the code doing the same thing . At the time I had a lot of Perl experience and could see looking at it the code size could be halved using a more powerful language, and in my opinion, that would have reduced the chance of repeating code (though to be fair the management practices were a far bigger offender).
Working on the code base with dynamic typing wasn't _that_ hard. Certainly not as hard as people make it out to be.