Part of the zen of Python is "Flat is better than nested". Until recently, I always thought of this at a code block/function level. Recently I realized that this is also important when modularizing and adding layers of abstraction. The more layers of abstraction (from foo.bar.baz import Baz) you add, the more code you write and have to "keep in your mind". This presentation by Jack Diederich at PyCon 2012 really opened my eyes to the potential problems of adding layers of abstraction via modules and classes: http://pyvideo.org/video/880/stop-writing-classes
Interesting you say that; I would argue (and have) the exact opposite. Good abstractions, by their very nature, reduce the amount of moving parts you have to keep in your head at any one time. When the number of "moving parts" created by your abstractions outnumbers the actual bits its abstracting, then you know your design took the wrong turn somewhere.
> When the number of "moving parts" created by your abstractions outnumbers the actual bits its abstracting, then you know your design took the wrong turn somewhere.
This is an interesting point which I agree with and is usually where I end up. In the past I've started from the opposite end, creating multiple modules, class hierarchies, etc. This future proofing has made things harder for me to follow/understand when reading at a later date. It has become tiresome and now I consciously start at the other end, making the simplest thing that could work. Layers of abstraction then come naturally as needed.
This is the best approach , but it is best combined with fairly comprehensive re factoring otherwise you end up in a situation I have been in a few times where you have new code that runs with a nice abstraction and old code that works with less abstraction.
At that point you can introduce bugs because somebody modifies the old code in a way which would not be allowed under the new abstraction and then the new code ends up reading data produced by the old code leading to a cascade of failure.
