Why whitespace denotation of blocks doesn't work.
Thaddeus L. Olczyk
olczyk at interaccess.com
Sat Jun 17 19:36:51 EDT 2000
On Sat, 17 Jun 2000 08:12:03 -0500, "Bob Hays, Computer Geek"
<rhays at interaccess.com> wrote:
>On Sat, 17 Jun 2000 07:49:43 GMT, olczyk at interaccess.com (Thaddeus L.
>Olczyk) wrote:
>
>The following are just my opinions to take or leave (probably the
>latter) as you wish.
>
>>1) The first is rather stylistic and may not appeal to most, but I
>>have often found it useful. When debugging code I often put in
>>code to help me figure out whats happening. I also avoid indenting
>>such code so that it easy to remember where it is later when I want to
>>take it out. An example ( assuming I use begin and end to denote
>>blocks ):
>
>I've gotten in the habit of putting the comment DEBUG on such lines in
>all programming languages; depending upon indention is very dangerous
>for debug lines since someone else may reindent the line properly and
>then it gets left in (since they didn't know it was a debug line).
>
I never check in code with debug lines in it, so I never have to worry
about others changing it. That's the whole point, it makes it easier
to remove.
>>2) You can easily insert a tab introducing a bug. Consider the
>>following code ( similar to a bug I recently fixed ):
>{Example skipped}
>>Initially the line in error was indented correctly, but someplace
>>along the line the extra tab was introduced. A lot of effort then had
>>to go in to finding this bug. With begin...end or braces this is less
>>likely to happen.
>
>Yep, this happens. Its a tradeoff - speed vs. occasional extra work.
What increases in speed do you get by having to type braces?
>
>In addition, I had an example, in C++, where someone had commented out
>a block of code, but then had an embedded inline comment inside that
>block, and, to top it all off, the less-than-desired commented out
>block would still compile - the guy worked on that bug for a day
>before coming to me. I loaded it into emacs and the color coding told
>him immediately what had happened; he was very ashamed and angry, but
>I told him sh*t happens:-).
>
But that's the point. His code was illegal, it wouldn't compile. Easy
to catch with emacs, and the compiler will catch it too. The little
typo I show is easy to make and perfectly legal code. Its hard to
accidentally bump against a keyboard and make a similar nasty typo.
EVen something that looks like it might work like }{ would have to be
put in just the right spot.
>>3) Finally. Python is a language where it is almost easy to write
>>extensible programs. To illistrate what I mean consider this example
>>of a python program I recently wrote:
>
>Here's were we will agree to disagree, I think. I think its way
>faster and easier to extend Python stuff than C++ (and Java) due to
>the lack of compile/link cycle and due to inheritance inside of
>Python. Yep, you have to be careful how you indent, but if you have a
>good editor it will cut/copy/paste as-is without reindenting. I see
>more problems due to bad cut/copy/paste reuse in all programming
>languages than I do from mis-indenting so far.
>
I think you misunderstood what I said. I think that Python is not now
easily extensible do to the problems with whitespaces. If that were
fixed then Python would be easily extensible.
The point is not that I can copy and paste with out reindenting.
The point is that sometimes I have to. let me show a generic example
if a:
for b in B:
if c(b):
block statement.
Assume that you are editing another part and you realise that you
are about to essentially retype the block statement. So you do
def fun():
block statement
if a:
for b in B:
if c(b):
fun()
you have to reindent the block statement. This is not copy and paste
reuse. It is cut and paste refactoring, and you have to reindent.
>>Anyway I hope this causes TPTB to think about how blocks should be
>>handled in Pyhton 3000.
>
>My personal moral - no programming language will save you from
>yourself - use good tools and do your best.
>
But there are some features in a language that make errors more
likely. Bocking by indentation is one of them. I shouldn't have
to be saved from this error in the first place.
More information about the Python-list
mailing list