&gt; If you move a block of code to a place just after e.g. a loop, it isn&#x27;t clear whether it should be inside or outside the loop, your editor cannot guess this. You still need to tell it at what level the new code should be inserted. And if the end of the loop happens to be nested further, the ambiguity is exacerbated.<p>1. Move the cursor to wherever you want to put the block
2. Hit paste
3. Your editor adjusts the indentation so the entire pasted block is inserted as if you just keyed it in<p>It&#x27;s simple and reliable and as a bonus it&#x27;s portable across any language where the code is indented correctly.<p>&gt; The closing brace doesn&#x27;t mean anarchy, or make the code harder to understand later.<p>It&#x27;s true that well-written C code can be almost exactly the same but the difference is that the world is full of sloppy C code where someone hammered out a bunch of changes, decided it was too much work to format it so the visual display matched the actual parsed structure, and left a trap for the next developer who touches that code. Yes, hopefully they&#x27;ll review &amp; test carefully but, as with e.g. memory management, we have decades of proof that depending on programmers to consistently follow desirable practice is a losing battle unless it&#x27;s enforced by tools.<p>The point isn&#x27;t that braces are bad and that whitespace is good but that Python will refuse to execute one class of sloppy code. Imagine if GCC made this flag mandatory or Clang refused to compile anything which didn&#x27;t pass cleanly through clang-tidy – the benefit wouldn&#x27;t be due to the braces but from the fact that one category of error would simply no longer be possible and every C developer on the planet would spend less time on cosmetic differences when reading other people&#x27;s code.