My personal beef with python..... I work in a unix environment. For better or worse, VIM is my preferred editor. I can safely say that I have a fairly 'standard' work environment for 'unix' type people. Still, I once had to maintain a (simple) python program. I could not add a single line of code without a compile error. It seems that the original programmer used tabs to indent the code, and I happen to 'expand' my tabs to spaces. While the code all looked like it was indented properly, the whitespace count was actually broken, so the code was broken even though it looked just fine. To me it is wrong that two pieces of code that look identical may behave differently. By way of example, what does the following python code do? if condition code-a code-b Well, first you have to know that my tab width is set to 2 characters, then, you have to know that spaces were used to indent the 'if' line and the 'code-a' line, but tabs were used to indent the 'code-b' line (though, mail software makes it hard to use actual tabs in the code above and ensure that everyone sees the same thing.... so I have replaced the tabs with equivalent spaces). Now, before you say that the programmer should use consistency in their white-space, realise that I do.... I use spaces. But, Python, by using whitespace to form logic structures, is vulnerable to all sorts of invisible failures that are obscenely hard to debug. All languages have their weaknesses. For me I find that white-space accounting is more stress than it is worth. I despise python as a result. Rolf Olin Lathrop wrote: > Peter Loron wrote: > >> Part of it is simply stylistic. I prefer to use braces to define >> nesting. >> > > Which is just reiterating that you don't like it because you don't like it. > > >> My beef with Python is that there is one way to do it, >> Guido's way. >> > > That's precisely the point. > > >> If you are using braces to indicate nesting, you can >> place them in many different ways. >> > > But this is the mess Python avoids. You haven't given any argument for why > having many different ways of formatting the same code is a good thing. > > >> You can achieve the same end-goal >> of helping coders write clear code (or even enforcing rigid code >> standards) by using a pre-commit hook on your version control system >> or as part of your build system. >> > > Why is it OK for the build system to enforce the rules but for the language > not to? The programmer still has to adhere to them either way. > > >> 2. Have the language syntax enforce formatting. >> 3. Have tools that review the code and enforce rules on formatting, >> etc. >> > > It seems to me the distinction between these two is of little consequence to > the programmer. Either way the code ends up adhering to the rules whether > the programmer likes the rules or not. The advantage of #2 is that the > enforcement is global, not just for your project or site or company. That > means it will be easier to include code received from other places since it > is guaranteed to follow the same rules, and everyone is used to looking at > and understands the same style. > > > ******************************************************************** > Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products > (978) 742-9014. Gold level PIC consultants since 2000. > -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist