While I believe it is an excellent idea to always use a clear and consistent indentation style when programming in any language, if I had been the BDFL for Python, I would not have made indentation be an intrinsic part of its syntax.
For instance, when cutting and pasting code snippets from other sources on the web or even when going between different code editors that I have, there have been times when I have had trouble getting the indentation implemented correctly. Some of this may be attributable to the use of invisible tab characters oin some of those other sources, so when I am coding Python from scratch, I stick with spaces and not tabs. In other languages (such as C++ and Objective-C) and in other IDEs (such as Visual Studio and Xcode) I routinely have taken advantage of their built-in tools to ensure that my code is indented properly. Having said that, I have learned to live with the fact that indentation is part of the syntax in Python and therefore enjoy those Python-aware editors that work nicely with the indentation. On Fri, Apr 22, 2011 at 9:25 AM, David Goldsmith <[email protected]>wrote: > > Date: Thu, 21 Apr 2011 10:50:03 -0700 > >> From: James Thiele <[email protected]> >> Subject: Re: [SEAPY] Introduction >> To: Seattle Python Interest Group <[email protected]> >> Message-ID: <[email protected]> >> >> I always have used indentation in languages using braces (C/Perl/C++/etc) >> even though it's not required. Just makes code more readable. >> >> Indeed: it's been a while, but IIRC, K&R (the inventors of C and authors > of what for a long time was THE text on it) _urged_ readers/prospective > programmers to use indentation for readability, despite their purposeful > design of the language to make it optional (allowed just a little too much > freedom, perhaps, but then they were NeXT when FORTRAN, COBOL, etc. were > already Microsoft and Apple, i.e., if they--or AT&T, as it were--wanted > "market share," they couldn't start out by limiting people; of course, the > primary motivation for this freedom, as we've already seen in this thread, > was probably simplification of the compiler's parser). > > DG >
