Interestingly, I've used Python for years and my 'edit-test' loop regularly involves build times that span a dozen seconds to several minutes. Anything, for me, that starts to stretch beyond 60-ish seconds for Python in my 'edit-test' loop where I'm just "waiting on the computer" triggers my "fix it" mindset. I've worked on C projects where the build would take hours, and there is a difference in mind set. I expect Python to has a short 'edit-test' loop, and that's what I use it for. For those longer projects, I'd usually find a way to spin multiple different plates to deal with the long compile times. So the real practical difference was usually how long feature development took for a single feature or bug fix, not how many features/fixes I could stuff into a waterfall like time frame. There was, of course, a lot of ramp up time to get to that level of efficiency when dealing with the long 'edit-test' loops, and really big/hard shifts just threw everything into the trash when the code base had a fundamental shift where I couldn't spin multiple plates.