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