Compare source code

[Tim Harig]

This is wishful thinking. Firstly, code written with a narrow
indentation offset (e.g., two spaces) can take up an uncomfortable width
when viewed with a wider offset.

I can accept that as a trade-off. People have different ideas about
acceptable column width anyway. I use 8 space tab stops and target
to no more then 80 columns. If somebody uses 2 space tab stops, its going
to go over the 80 columns a little bit; but, not so much as cause a major
issue.

Secondly, if you want other parts (e.g., per-line comments) of lines
with different indentations to align, then you'll have to take into
account the tab width. Technically, you could arrange that between any
pair of alignment points of any pair of lines there are the same number
of tab characters; but this is also doomed to uncomfortably wide lines;
it also suffers because it imposes an /a priori/ upper bound on the
indentation level.

I use simple comments that are not effected by white space. I don't waste
my time trying to make comments look artistic. They are there to convey
information; not to look pretty. I really detest having to edit other
peoples comment formatting where you have to re-align everything if the
length of any of comment lines change.

 

[Tim Harig]

Right. If you mangle spaces in Python or mangle braces in C then
recovery becomes impossible. I don't think anyone is contesting that.

Examples of communication channels that mangle white space abound. I don't
know of any that mangle either braces or pascal style start/end blocks.

You are the one who seems to be on a crusade against against braces. It
would seem to me, that if you want people to accept that white space
formatting is superior, that you would be looking for a simple way to solve
the white space mangling problem.

What we question is the idea that somehow Python is special in this
regard. If you move files around in ways that change them then your
tools are broken. The fact that the breakage is somewhat "friendlier"

The world is full of broken tools that many of us have to use; but, why
should we accept that your choice is superior when other choices manage to
work with these tools without issues.

tools are broken. The fact that the breakage is somewhat "friendlier"
to some types of files is interesting but irrelevant. What would you
say to a file transfer program that changed Word documents? What about
executable files?

Transfering binary programs has always been an issue and using text based
communications (preferably human readable) has always been considered a
good design decision. I put up with Python's white space idiosyncrasies;
I wouldn't even bother looking at a language that requires me to enter
the source in binary. I also consider the move toward XML based document
formats a move in the right direction.

 

[D'Arcy J.M. Cain]

You are the one who seems to be on a crusade against against braces. It

You totally misunderstand me. I am not on a crusade of any sort. I am
happy with Python and the number of other people who are happy with it
is interesting but does not change my life in any significant way. As
long as there are enough people using it to keep it alive that's all I
care about. If no one was on a crusade to convince people that
indentation as syntax (can we call is IAS from now on?) was evil then I
wouldn't be posting anything at all on the subject. I am being totally
reactionary here.

would seem to me, that if you want people to accept that white space
formatting is superior, that you would be looking for a simple way to solve
the white space mangling problem.

I might if it was a problem for me.

The world is full of broken tools that many of us have to use; but, why
should we accept that your choice is superior when other choices manage to
work with these tools without issues.

You don't have to accept anything. Choose your own tools. I happen to
choose Python and the tools that I choose to use work fine for me.

the source in binary. I also consider the move toward XML based document
formats a move in the right direction.

Don't get me started on XML. ;-)

 

[Seebs]

Right. If you mangle spaces in Python or mangle braces in C then
recovery becomes impossible. I don't think anyone is contesting that.
What we question is the idea that somehow Python is special in this
regard. If you move files around in ways that change them then your
tools are broken. The fact that the breakage is somewhat "friendlier"
to some types of files is interesting but irrelevant.

Again, why does "diff -b" exist?

It exists because so many things change whitespace unintentionally that
it's a common failure mode. Thus, people developing data file formats
often put substantial effort into *guaranteeing* that they will survive
changes to the contents of blocks of whitespace -- it won't matter
whether you used spaces or tabs, or how many spaces there are. This
is done because, if you don't do it, your files sometimes get broken.

I have never heard of a problem where sending something via a common
commercial mail client with its default settings resulted in the
destruction of braces. I have regularly seen people report that one
mail client or another is losing or adding spaces, converting tabs
to spaces, converting spaces to tabs, or whatever.

To some extent, it may be largely a matter of convention; it is
conceivable that, had Python been a major and influential language
in 1970, tools in general would be much more careful about preserving
spaces. But that's not what happened. Python was created in a world
where the decision had already been made by many engineers (often
poor ones) that it was not a big deal to mess up spacing a bit.

I'd guess this decision goes back to early typesetting. Spaces
are fungible; other content isn't. The distinction that is tracked
is "was there space between these characters or not". Given that
widespread presupposition, and that many file formats have been
adapted to that, I don't think it was a good choice to build
something which would be broken by that common failure mode.

It's not as though widespread spacing problems are a surprise. They
are so commonplace that multiple utility programs provide, as standard
options, features to work around them.

-s

 

[Seebs]

So you've not tried Lisp, then? Dissing Lisp's parentheses tends to get
a pretty similar reaction.

I don't use it. I'm also not as sure that the parens are an obvious
flaw -- I am not aware of whole categories of software which regularly
destroy parens.

* I /do/ have a significant problem with cutting and pasting code in
Python. In most languages, I can haul a chunk of code about, hit
C-M-q, and Emacs magically indents the result properly. This is,
unfortunately, impossible with Python. It has caused me real bugs,
and I have to be extra careful to fix the indentation up.

That was the thing which bit me the worst. I had a fairly large block
of code in a first-pass ugly program. I wanted to start refactoring
it, so I moved a big hunk of code into a method (with plans to further
refactor). It took about fifteen minutes to redo the logic.

I /like/ Python. I use it frequently. I /don't/ want to change its
structure marked by indentation. I'm /willing/ to put up with some
inconvenience because Python makes up for it in other ways. But there
/is/ inconvenience, and it does need putting up with. I think the
benefits are worth the costs; others may disagree.

That makes sense to me. I think it depends a lot on what I compare
Python to. I get along quite well with Ruby, but I loathe PHP. Comparing
Python to Ruby, I find the indentation quite annoying. Comparing Python to
PHP, I find the indentation a very mild price to pay for my sanity.

-s

 

[Mark Wooding]

I use simple comments that are not effected by white space. I don't
waste my time trying to make comments look artistic. They are there
to convey information; not to look pretty. I really detest having to
edit other peoples comment formatting where you have to re-align
everything if the length of any of comment lines change.

I view source code as primarily a means of communication with human
readers, and only secondarily as being machine readable. I therefore
think it's worth the effort to make source code readily legible, for
example by making effective use of horizontal and vertical whitespace.
A long time ago, I spent a little while studying graphic design, so I
try to keep an eye on this sort of thing.

I'm interested in line length for two reasons: firstly, because I
believe that there's an optimum line length for easy and rapid reading,
which is probably a bit less than 80 columns; and secondly because I
find that I make more effective use of the available space on my screen
if I have several narrow columns rather than a few wide ones -- since
most lines in source files are short, a wide column ends up being mostly
empty on the right hand side, which is wasteful.

It's true that a source file is not the same as a typeset document: the
most obvious difference is that source files are modified over time,
sometimes by many hands, and that therefore some of the tradeoffs are
different. I dislike `pretty' boxes around large comments, for example,
because maintaining the right hand edge is unnecessarily tedious. But
sometimes careful alignment can help a reader spot a symmetry or find
his way through a repetitive section such a table more easily.

(Unfortunately, I appear to have strange ideas about what `legible'
means...)

-- [mdw]

 

[Grant Edwards]

Again, why does "diff -b" exist?

It exists because so many things change whitespace unintentionally that
it's a common failure mode.

It exists because so many people change whitespace intentionally in C
source code because no two C programmers seem able to agree on how to
format code. Diff -b allows you to attempt to ignore semantically
null stylistic changes made by programmers.

 

[Terry Reedy]

On 11/4/2010 4:17 AM, Seebs wrote:

I am sorry you feel compelled to use a language you so dislike. Not our
fault though.

Other languages I use are mostly amenable to the development of tools
to automatically indent code. Makefiles and Python are the only two
exceptions...

If you add the normally redundant information in the form of explicit
dedents (anything starting with '#' and distinguishable from normal
comments), then it is not too hard to re-indent even after all indents
have been removed. I believe this has been dome more than once. By using
a stylized comment, the augmented code runs without preprocessing. I
also believe at lease one person has written a preprocessor for
'python-with-braces'.

 

[Tim Harig]

I view source code as primarily a means of communication with human
readers, and only secondarily as being machine readable. I therefore
think it's worth the effort to make source code readily legible, for
example by making effective use of horizontal and vertical whitespace.
A long time ago, I spent a little while studying graphic design, so I
try to keep an eye on this sort of thing.

I agree that it should be clean, ledgible, and easy to parse; but, I can
that I can achieve this without making too many assumptions about
whitespace. Think of it like the way HTML is *supposed* to work. Ideally,
the web designer should stipulate the basic layout of the page; but,
details such as how wide the display is are better left to the browser to
figure out based on the actual conditions that it needs to display the
page.

I'm interested in line length for two reasons: firstly, because I
believe that there's an optimum line length for easy and rapid reading,
which is probably a bit less than 80 columns; and secondly because I
find that I make more effective use of the available space on my screen
if I have several narrow columns rather than a few wide ones -- since
most lines in source files are short, a wide column ends up being mostly
empty on the right hand side, which is wasteful.

Don't get me wrong, I am not arguing against the eighty column stylistic
limit. I totally agree with it within reason.

What I am arguing for is choice on how the code is displayed -- not how it
is actually written. By using tabs, I can choose the trade-offs myself
when reading the code rather then being confined to how the writer made
their decision to view it. Assuming that I have sufficient screen space,
I might choose a wider indent even though it might make the document wider
then 80 columns *when viewed*. Other times, I may resign to view at the
shorter column width so that it fits in my window without side scrolling.
Either way, its my choice; and, when I am finished editing the file,
even if it exceeds 80 columns at my chosen column width, the file will
not exceed 80 columns, at the origional column width, in the actual
source as it is *written*.

Adjusting tab stops is merely for my viewing pleasure and it gives
everybody the choice to view it their way without effecting the code. That
is why I prefer tabs.

 

[Tim Harig]

It exists because so many people change whitespace intentionally in C
source code because no two C programmers seem able to agree on how to
format code. Diff -b allows you to attempt to ignore semantically
null stylistic changes made by programmers.

I have seen huge patches caused by nothing more then some edit that
accidently added a trailing space to a large number of lines. White space
mangling happens all the time without people even knowing about it.

 

[Seebs]

It exists because so many people change whitespace intentionally in C
source code because no two C programmers seem able to agree on how to
format code. Diff -b allows you to attempt to ignore semantically
null stylistic changes made by programmers.

I don't agree with this interpretation, just because the changes it
filters out are hardly ever intentional when I actually look at them.

They're a mix of space/tab changes which don't affect actual indentation,
trailing whitespace, and the like.

The kinds of changes that would be made by C programmers trying to change
source formatting are usually far beyond what "diff -b" would "fix".

-s

 

[Seebs]

I am sorry you feel compelled to use a language you so dislike. Not our
fault though.

I don't dislike it all that much. What I dislike is being told that the
problems don't exist.

If you add the normally redundant information in the form of explicit
dedents (anything starting with '#' and distinguishable from normal
comments), then it is not too hard to re-indent even after all indents
have been removed. I believe this has been dome more than once. By using
a stylized comment, the augmented code runs without preprocessing. I
also believe at lease one person has written a preprocessor for
'python-with-braces'.

Yes. They did this because there is no reason that anyone would ever
prefer it or find some benefit to it, of course.

-s

 

[Alain Ketterlin]

If you add the normally redundant information in the form of explicit
dedents (anything starting with '#' and distinguishable from normal
comments), then it is not too hard to re-indent even after all indents
have been removed.

I actually use such a trick in emacs, not with comments but with "pass"
(emacs' python mode knows that pass end return end the current block).
It's extrememly useful in heavily nested code, or if I need to paste
some piece of code from one level to another. This lets my editor's
auto-indenter do the right thing. And I see immediately if/when I did
the nesting wrong.

I really like "indentation as structure" (code is more compact and
clearer), but I really hate that it relies on me putting the right
spaces at the right place. I would love to be able to put, e.g., a
period at the end of a line, to indicate that the next line is one level
upper. Something like:

for i in ... :
for j in ... :
whatever(i,j).
.

No lost vertical space (except when I decide it), no ambiguity. It looks
to me like the exact opposite of ':'. End-of-line periods (or
exclamation marks) would let tools reindent correctly in all cases. I
don't think it conflicts with any other syntax.

-- Alain.

 

[Steven D'Aprano]

I really like "indentation as structure" (code is more compact and
clearer), but I really hate that it relies on me putting the right
spaces at the right place.

Er what? You really like indentation as structure, but you don't like
putting in the indentation?

I would love to be able to put, e.g., a
period at the end of a line, to indicate that the next line is one level
upper. Something like:

for i in ... :
for j in ... :
whatever(i,j).
.

How is that different from this?


for i in ... :
for j in ... :
whatever(i,j)


What's the point of the dots? Is that just to save you from having to hit
shift-tab (or whatever your editor's decrease-indent command is)?

No lost vertical space (except when I decide it), no ambiguity.

What lost vertical space are you worried about?

It looks
to me like the exact opposite of ':'. End-of-line periods (or
exclamation marks) would let tools reindent correctly in all cases. I
don't think it conflicts with any other syntax.

for i in ... :
for j in ... :
n = 2.

 

[Steven D'Aprano]

I have seen huge patches caused by nothing more then some edit that
accidently added a trailing space to a large number of lines. White
space mangling happens all the time without people even knowing about
it.

How does an edit accidentally add a trailing space to a large number of
lines?

(1) The programmer shifted the cursor to the end of the line, pressed
space, moved down a line, shift to eol, press space, repeat a large
number of times. I don't call that an "accident".

(2) Some programmer used a tool that thought it was okay to add
whitespace to the end of lines without being told to. I don't call that
an accident either, I call that using a broken tool.

So we keep coming back to work-arounds for tools that mangle your data
for no good reason...

 

[Steven D'Aprano]

That was the thing which bit me the worst. I had a fairly large block
of code in a first-pass ugly program. I wanted to start refactoring it,
so I moved a big hunk of code into a method (with plans to further
refactor). It took about fifteen minutes to redo the logic.

Well there's your problem -- you are relying on tools that operate by
magic.

Rather than re-create the logic, why not just hit Undo and then re-paste
the code *without* the magic auto-reformat? Half a second, to undo and re-
paste, followed by 10 or 20 seconds to select the appropriate lines and
*explicitly* re-indent the lines to the correct level.

For somebody who keeps tossing around the mantra that "explicit is better
than implicit", you're amazingly reliant on a tool that performs massive,
apparently irreversible formatting operations implicitly. And then rather
than accept that your magic DWIM tool is unsuitable for the task you are
putting it to, you then blame the data for not having error-correction
codes that would allow *another* magic tool to fix the breakage caused by
the first magic tool!

 

[Alain Ketterlin]

Er what? You really like indentation as structure, but you don't like
putting in the indentation?

Exactly. I want the extra safety belt of not relying on spaces only.

How is that different from this?

for i in ... :
for j in ... :
whatever(i,j)

At this point exactly, there's no way to know what the indentation of
the next line should be. My example above explicitely indicates the next
line should be at the same level as "for j ...".

Now suppose that, at this very place, you have to paste some other
if/for/while block whose original indentation is not exactly aligned
with the fragment above. No way to decide automatically how to align it
(under "for j"? under "whatever"?).

The dots I suggest are nothing more than tiny closing braces.

What's the point of the dots? Is that just to save you from having to hit
shift-tab (or whatever your editor's decrease-indent command is)?

Redundancy. I often have deeply nested constructs, that I sometimes need
to move around. A real pain, compared to brace-based languages, where
constructs are explicitely terminated (i.e., not implicitely by the
start of the next construct). Have automatically indented source is a
useful and quick check.

What lost vertical space are you worried about?

You've cut the part of my message where I say that python's (vertical)
compactness is one of its strong points.

for i in ... :
for j in ... :
n = 2.

You're right, I forgot this one (probably because I never use this kind
of elision). No big deal:

for i in ... :
for j in ... :
n = 2.
m = 3. .
for j in ... :
f = 2 .
...

-- Alain.

 

[Ethan Furman]

Unless, your code is split over different pages, as when it is printed in a book.
You also need to see the next piece of code to notice the dedention.

e.g. I have the following code at the bottom of my editor.

for i := 0 to 9 do
some(code);
more(code);
end;

I can by just looking at this code notice that I'm looking at the whole for block.


But when I have similar python code at the bottom of the page.

for i in xrange(10):
some(code)
more(code)

Then I can't make out whether I'm looking at the whole for suite or not.

These code pieces are not equivalent -- you have four lines of code in
the first piece, only three lines in the python piece; in other words,
if the "end;" were not on screen, you would still have no idea if it was
the whole block or not; in still other words, the "end;", just like the
dedented line, provides the context.

~Ethan~

 

[Ethan Furman]

But without the colon, how are people who write programming editors
going to know when to increase the indentation level as I enter code?

Hopefully by the keywords used to introduce the block: if, elif, else,
for, while, with, etc. etc. It is not legal to start a new indented
block just by appending a colon to the previous line.

~Ethan~

 

[Tim Harig]

How does an edit accidentally add a trailing space to a large number of
lines?

Putting it back in context, it doesn't matter. Seeb's point stands.
diff -b was designed because there are so many tools and channels that
mangle whitespace. Changes in something such as brace style would make
non-whitespace changes that would not be eliminated by diff -b.

Probably the biggest reason for -b is for handling the differences in line
endings used on different platforms.

(1) The programmer shifted the cursor to the end of the line, pressed
space, moved down a line, shift to eol, press space, repeat a large
number of times. I don't call that an "accident".

A search and replace operation could easily add extra whitespace and since
whitespace is not normally visible, the changes most likely go unnoticed.
The bottom line is that it happens and assigning blame really doesn't
change that fact.

(2) Some programmer used a tool that thought it was okay to add
whitespace to the end of lines without being told to. I don't call that
an accident either, I call that using a broken tool.

Yep, there are probably thousands of tools that mangle whitespace. In many
cases, such as differences in line endings, what they are doing is not even
wrong. You can blame the tools all you like; but, they are not going away.

You keep trying to tell us that using whitespace is superior; but,
other languages manage to work with these thousands of imperfect
tools without issue. The use of whitespace was a stylistic change and
stylistic holy wars exist because it is almost impossible to prove that
any reasonable style has benefit over another. That whitespace causes
issues is verifiable. I find it hard to concluded that that whitespace
based syntax is superior when it tells us that we cannot use thousands
of otherwise useful tools that other langauges manage to work with.
I find it hard to select a matter of taste with no verifiable benefit
over a verifiable disadvantage that happens to strike many people.