> My bad. I had meant significance beyond token separation I.e. Use in > Control flow.
It has significance beyond token separation anyway, e.g. in multiline string literals (have to escape or specially quote whitespace), or the use of ^L in some code to block out areas of functionality. Python just formalises one more of those levels of significance than other languages. > Ya well "belts and braces" is not always a bad thing when it comes to > code. Absolutely! But in this context, the most reasonable interpretation of "belts and braces" is not only indenting your code consistently as a matter of principle, but in addition ensuring that it really is consistent, which assurance you get for free by linking it to code structure. > I believe one of the common problems is with auditing code with blocks > that cross more than one screen. I end up with fingerprints on my > screen rather than using the auto brace matching built into my editor. If the code block is that long (I assume only while you're busy refactoring it ;-) ), then brace matching will end up bouncing between a screenful of code at the start and one at the end of the block; rather disorienting. I'd :split the window to have the start and the end of the block in view at once, and this would work just as well with indentation levels as with braces. Sometimes I :vsplit and :scrollbind to have one 110-line window snaking across my screen, if I really want to have a long skein of code in view at once. This back 'n' forth is fun, like a solitaire game, different ways of dealing the cards, but the end result the same .. -- jean . .. .... //\\\oo///\\ _______________________________________________ Slugnet mailing list [email protected] http://wiki.lugs.org.sg/LugsMailingListFaq http://www.lugs.org.sg/mailman/listinfo/slugnet
