Whitespace as syntax (was Re: Python Rocks!)

[David Max]

"Aahz Maruch" <aahz at netcom.com> wrote in message
news:87np2g$kc8$1 at nntp1.atl.mindspring.net...
> Speaking as a programmer with more than twenty years of experience and a
> Python user with less than a year of experince, it is precisely that
> whitespace-based syntax that accounts for much of Python's usability in
> a multi-developer environment.  Every Python program written by someone
> with a jot of care has almost the same layout; this greatly enhances
> readability.
>
> I still curse regularly when I get tripped up on some whitespace
> (particularly while trying to add debugging code quickly), but I think
> the benefits greatly outweigh the drawbacks.

I'm a programmer new to Python. So far the whitespace issue hasn't really
bothered me, but as someone who in the past has occasionally wasted an hour
trying to fix a broken makefile because of some tab/space mixup, I'm staying
vigilent. Every language I have ever dealt with has its own peculiar tricks
to adapt to. For example, who hasn't gotten bitten by some mistake in
keeping C++'s 18 levels of operator precedence straight? Anybody here
confident enough to guess whether ptr->x++ and *ptr.x++ are equivalent? You
think the next developer is going to remember either? So you end up writing
((*ptr).x)++ just to make sure.

Python's treatment of whitespace has plusses and minuses. I've seen a lot of
good pluses mentioned in this thread, but one minus is that people who
aren't accustomed to caring about spaces, tabs, or whitespace in their code
are going to have to learn to care (and really, can learning to care really
be a bad thing? ;-). So far, I think that on balance the positives outweigh
the negatives. Also, the creation of tools like TabNannies and Python-aware
editors make it less likely to stumble into a whitespace problem
accidentally. This is not unlike how brace-kissing has helped LISP coders
and chromacoding has stopped C programmers from accidentally leaving
unclosed /* comments.

So my point is that what is needed is not religious wars but advice from the
experienced on how they avoid the pitfalls and continuing refinement in the
programming tools that keep us programmers from having to worry about these
things.

- David Max

P.S. The "." and "->" operators have higher precedence than "++" and "*" in
C++.
So ptr->x++ is (ptr->x)++ and *ptr.x++ is (*(ptr.x))++, which probably won't
compile anyway.
And if any of you are still pulling out your reference book just to check,
that just proves my point.