Re: [TUHS] 80 columns ...

Nemo: And for that reason, I have never used Python. (I have a mental block about that.) ==== I used to feel the same way. A few years ago I held my nose and jumped in. I'm glad I did; Python is a nifty little language that, now I know it, hits a sweet spot twixt low-level C and high-level shell and awk scripts. Denoting blocks solely by indentation isn't at all bad once you do it; no worse than adapting from do ... end to C's {}. What still bugs me about Python: -- It is unreasonably messy to give someone else a copy of a program composed of many internal modules. Apparently you are expected to give her a handful of files, to be installed in some directory whose name must be added to the search path in every Python source file that imports them. I have come up with my own hacky workaround but it would be nice if the language provided a graceful way to, e.g., catenate multiple modules into a single source file for distribution. -- I miss C's style of for loop, though not often. (Not quite everything can be turned into a list or an iterator.) -- I miss one particular case of assigment having a value: that of while ((val = function()) != STOP) do something with val Again, there are clunky ways to work around this. As for 80 columns, I'm firmly in the camp that says that if you need a lot of indentation you're doing it wrong. Usually it means you should be pulling the details out into separate functions. Functions that run on for many, many lines (once upon a time it was meaningful to say for many pages, but no longer) are just as bad, for the same reason: it's hard to read and understand the code, because you have to keep so many details in your head at once. Likewise for excessive use of global variables, for that matter, a flaw that is still quite common in C code. Having to break an expression or a function call over multiple lines is more problematic. It's clearer not to have to do that. It helps not to make function or variable names longer than necessary, but one can carry that too far too. Style and clarity are hard, but they are what distinguishes a crap hack programmer from a good one. Norman Wilson Toronto ON (Sitting on the lower level of a train in Texas, not on a pedestal)