A modest indentation proposal
chrishbarker at home.net
Fri Nov 30 19:32:38 CET 2001
Erann Gat wrote:
> Yes, this is exactly my point. You can look at the above code and tell
> there's something wrong because the braces and indentation provide
> redundant information in C.
This doesn't make any sense to me. On the one hand, you want to be able
to cut & paste code. With delimiters defining blocks, you can do this,
and have the editor fix the indentation for you. That's a nice feature,
and I do use it a lot, but frankly, you can just as easily screw up the
delimiters when you cut&paste (or any edit) as you can screw up the
indentation in Python, and when you do so, no editor is going to correct
it for you. But what it can do is make the indentation match the
delimiters, and then you have a visual clue that something is ammiss:
another nice feature. But wait...
> No, that's not true. Consider the following two alternative code fragments:
> if x:
> if x:
> They both look right, but they can't both be right.
So you don't think that indentation provides the required visual clue.
So you are just plain stuck here, Nothing is going to help you.
Both of these are valid C, but if you ask me, it is harder to tell them
apart than the Python example. To fix this, you would run your editors
indent_for_me function, and get this:
Ah! now I can see the difference! So, to see the error, you need the
indenting to match what the compiler will see. That is exactly what you
always get with Python, without having to remember to run the editors
indenter. The block delimiters are at best redundant, and at worse error
Also, I imagine that your co-workers do accept C, and as Skip points
out: C does not require delimiters around blocks of only one line. This
is going to cause a whole lot more errors than the Python way.
> The reason is that I want to sell
> people at JPL on the idea of using Python to write mission-critical
> software, and the people I'm trying to sell are raising this objection. I
> can counter this objection, but only three-quarters of the way. I can
> point out that Python already provides enough redundant information to
> reconstruct corrupted indentation at the beginning of blocks, but not at
> the end. To reconstruct it at the end of blocks all I can offer is my
> "pass/return" hack.
You're barking up the wrong tree. No language provides redundant
information that lets you re-contruct how what the programmer intended
when that is different than the code. In C, if you screw up a }, the
code is wrong and no editor is going to fix it. All the editor can do is
re-indent and give you a clue that something is amiss. Python already
does that by default.
People are often adverse to a new thing. What I try to do when
evaluating methiod A vs. method B is to find people that have used both,
and ask them. Darn few people that have used Python to any degree find
the indentation to be a problem. Most of us have used other languages,
and tried the other way as well. Many of us found the indentation thing
disconcerting at the beginning as well.
By the way, if there is any problem with indentation with Python, is
that tabs and spaces can be mixed, but you can turn that off by running
Python with the -tt switch. (I only just learned that!)
> I'd really like to be able to offer a standard
> syntactic convention that is endorsed by the Python community.
There is one. It's known as indentation ;-)
To everyone else: Has a document been created that puts forward a cogent
argument about this??? If so it needs to be featured front-and-center
ont he web site. If not, I suppose we need to write it, this is the last
long email I will write on the subject, and the last long thread I will
ChrisHBarker at home.net --- --- ---
http://members.home.net/barkerlohmann ---@@ -----@@ -----@@
------@@@ ------@@@ ------@@@
Oil Spill Modeling ------ @ ------ @ ------ @
Water Resources Engineering ------- --------- --------
Coastal and Fluvial Hydrodynamics --------------------------------------
More information about the Python-list