Compare source code

[Tim Harig]

"Redundant" is right. However, there is a use for such comments:

if foo:
bar
else:
baz
if snafu:
cookie
#endif snafu
quux
#endif foo

Actually, I have found similar markers to be useful everywhere. I don't
like the way my editor tries to fold Python code, so I started inserting
folding markers myself:

# foo {{{
if foo:

bar

else:

baz

# snafu {{{
if snafu:
cookie
# }}}

quux

# }}}

If the bar, baz, and quux blocks are large enough logical units, I will
fold them as well.

What I found is that the makers become an incredibly useful form of
organzational tool.

 

[Seebs]

"Large" is no excuse for incompetency.

It is in practice.

So configure it to recognize Python files and act accordingly.

So far as I know, it doesn't have a feature to do this. In any event,
I work around it okay.

And C has the same problem.

Not quite!

if (foo)
bar;
else
baz;

quux;

Is quux meant to be part of the else clause? The writer's indentation
suggests "yes" but the code says "no".

Right.

And that's the thing: In C, I know there's something wrong here. I may not
know what it is, but I know *something* is wrong.

Same is true for the C code.

Pretty much!

In both cases you can tell what the code
will do (modulo weird macros in the C code) but the intention is
impossible to determine without mind reading abilities in both cases.
We do know that the Python code *appears* to be doing exactly what the
author intended and the C code *appears* to not be.

Yes. And in my experience, that means that since the code must be
wrong (or I wouldn't be looking at it), it's very nice that in one of
them, I've just been told for sure that the writer was confused right
here at this line. In the other, I have no way of knowing that the
writer was confused.

What was it someone once said? "Explicit is better than implicit."

I *like* my parity bits.

-s

 

[Seebs]

What is right is that there's no question that quux is subsequent to baz
in all cases barring exceptions (and assuming no tabs intermixed)

Yes, but that doesn't mean it does what the programmer intended, just
that it does what it does.

The apparent structure in python _is_ the structure, whereas otherwise
you've got to count your ;'s and {}'s etc to determine and verify the
structure matches the apparent structure provided by the programmer.

Yes.

I understand this.

However, I have probably seen all of two or three bugs ever related to
mis-indented C, and I've had various things screw up or wreck indentation
on dozens of occasions. Being able to recover has been nice. (So's being
able to use fence matching to jump to the other end of a block.)

-s

 

[Seebs]

This is Python's most noticable blemish outside of the community.
Everybody knows that Python is the language that forces you to use a
particular style of formatting; and, that is a turn-off for many people.

Honestly, I could probably live with that; the killer is the impossibility
of recovering from white space damage. I have had many things happen to
code over the years which required someone to run them through indent/cb.

It is a big mistake that whenever the issue arises, the community
effectively attacks anybody who might have disagreements with the tradeoffs
made for the Python language. This tends to set people on the defensive
and gives them a bad taste about the language as a whole.

Yes. It does not create an impression that this is an engineering tradeoff
which has been considered and understood; it creates the impression that
people are defensive enough about it that they're not able to confidently
acknowledge the shortcomings while maintaining that the tradeoff is worth
it.

I like C. If you tell me that C's macro processor sucks, I will agree
with you. I don't have to make excuses or pretend that there's no
downsides; I can justify my preference for the language even *granting*
those downsides (and downsides aplenty are to be found).

It would be much better if the community would simply acknowledge that
this is a tradeoff the the language has made and one which is often
misunderstood by many first time Python programmers. Then it is possible
transition to Python's strengths. Don't simply ignore that there *are*
potential downfalls to this approach.

Amen.

I am fine with this tradeoff. It's not what I would have picked, but
hey, I'm not Dutch. What I'm not fine with is people telling me that
it's not a tradeoff and that all the problems are my fault.

If someone designed a protocol where a particular kind of file was required
to be sent via email, as plain text, with many lines starting "From ", and
the protocol died horribly whenever it encountered ">From " at the
beginning of a line, no amount of pointing out that the mail servers in
question were wrong would make it a good design for a protocol.

Whitespace damage is, indeed, wrong. It's a bad thing. It is an
*extremely common* bad thing, and I fundamentally don't think it was
a good choice to build a system with no redundancy against it. That
"redundant" information saves our hides on a regular basis in an
imperfect world.

-s

 

[Seebs]

Huh? Indentation is invisible? You can't see the indentation in
Python source code?

The difference between tabs and spaces is invisible on a great
number of the devices on which people display code.

Indentation is visible, but the underlying structure of it may not
be. (It's worse than that, because for instance " " is
quite hard to distinguish from the quite similar " ".) And at
least one of them is clearly wrong.

-s

 

[D'Arcy J.M. Cain]

Actually, I have found similar markers to be useful everywhere. I don't
like the way my editor tries to fold Python code, so I started inserting
folding markers myself:

# foo {{{
if foo:

Now that is redundant. We know it's "foo" at the top of the block.
Identifying the end of the block has some value. And the braces just
make the code noisy.

 

[D'Arcy J.M. Cain]

However, I have probably seen all of two or three bugs ever related to
mis-indented C, and I've had various things screw up or wreck indentation

Really? I have never seen bugs in C related to indentation. I have
seen plenty related to braces. What I have seen is bugs hidden by the
indentation not matching the block structure. Wrong indentation in
Python *is* a bug. There's no other visual signal to hide the error.

on dozens of occasions. Being able to recover has been nice. (So's being
able to use fence matching to jump to the other end of a block.)

But I can see the other end of the block in Python. I don't need any
tricks to make sure that it is the end. And if your block is too big
to see the structure easily then that just means that some code should
be factored out to a method.

 

[Tim Harig]

Now that is redundant. We know it's "foo" at the top of the block.

In practice the comment would explain why and how the conditional is
being used just like any other comment. Since your example as abstract,
I didn't have anything useful to say about it as I would for real code.

When the code is folded, I will see nothing but the comments. It is often
helpful to look at a section of code with all of the code blocks folded to
gain a high level understanding of the code before zeroing in on the
specific section that I wish to edit. When I do edit a section, I unfold
no more code blocks then necessary. If I have to unfold too many blocks to
to edit a single section of code, then it is a powerful indication that
either the code block is not properly self contained or that the comments
of the surrounding code blocks are insufficient to convey information about
their code block.

Identifying the end of the block has some value. And the braces just
make the code noisy.

With good syntax highlighting, you don't notice them unless you are looking
for something because the markers are in comments and the markers for
a block are only visible when the block is unfolded. As a benefit, they allow the folding
stucture to provide expression of the code structure that cannot be
expressed in the code itself.

I often group blocks together that would not otherwise be indented or
otherwise expressed together as they were in your example.

# top level group {{{

# part 1 {{{
code
# }}}

# part 2 {{{
code
# }}}

# part 3 {{{
code
# }}}

# }}}

Folded in my editor, it looks like this:

44 +--- 15 lines: # top level group -------------------------------------------

Unfolding the top level group, it looks like this:

44 # top level group {{{
45
46 +---- 3 lines: # part 1 ---------------------------------------------------
49
50 +---- 3 lines: # part 2 ---------------------------------------------------
53
54 +---- 3 lines: # part 3 ---------------------------------------------------
57
58 # }}}

It is therefore clear that all three of the parts are logically connected.
I can keep them all folded and view them as a group or a can look into the
group and edit just the relevant section of the group:

44 # top level group {{{
45
46 +---- 3 lines: # part 1 ---------------------------------------------------
49
50 # part 2 {{{
51 code
52 # }}}
53
54 +---- 3 lines: # part 3 ---------------------------------------------------
57
58 # }}}

I have effectively added a meta structure to the blocks inside of
the fuction at a finer grain then is supported by the syntax itself.
Should I decide later that the top level group is becoming autonomous
enough to warrant moving to a separate function, I can simply grab the
entire folded block as an entity and move it to its own function body.

 

[Tim Harig]

With good syntax highlighting, you don't notice them unless you are looking
for something because the markers are in comments and the markers for
a block are only visible when the block is unfolded. As a benefit, they allow the folding
stucture to provide expression of the code structure that cannot be
expressed in the code itself.

Also note that you can use whatever you like for the folding markers if the
braces intimidate you. {{{ just happens to be the most recognized
standard. The Erlang crowd like to use ## for this sort of thing.

 

[Seebs]

Really? I have never seen bugs in C related to indentation. I have
seen plenty related to braces. What I have seen is bugs hidden by the
indentation not matching the block structure.

Right. That's *related to* indentation -- it wouldn't be there (we hope)
had the indentation been right.

Wrong indentation in
Python *is* a bug. There's no other visual signal to hide the error.

Sure, but there's also no way for you to spot that something looks
suspicious. In Python, if something is misindented, it does what you
told it to do, and there's no way for you to tell, by looking at it,
that it isn't what was intended. In C, if something is misindented,
it does what you told it to do, but it's obvious looking at the code
that something went wrong.

But I can see the other end of the block in Python. I don't need any
tricks to make sure that it is the end. And if your block is too big
to see the structure easily then that just means that some code should
be factored out to a method.

This level of dogmatism about what should always be the case is not
conducive to good software engineering practices. It is not obvious to
me that it's *always* the case.

-s

 

[Steven D'Aprano]

I agree with Seebs, Python is the only language I know that promotes the
use of spaces over tabs;

Really? I'm not aware of *any* language that promotes tabs over spaces. I
thought the tabs vs spaces war was mostly won by spaces over a decade ago
(apart from a few plucky freedom fighters who will never surrender).

and there are equally picky syntaxs (ie,
Makefiles) that mandate the use of tabs. I personally prefer tabs as it
lets *me* decide how far the apparent indentations are in the code. You
may like four spaces; but, I agree with Linus Torvalds that eight spaces
is much clearer. The beautiful thing about tabs is that we can both set
our tab stops to match our own viewing preferences.

Actually I agree with you about tabs. I think tabs are far more logical
and sensible. But I'm stuck with broken tools that don't deal with tabs,
and with PEP 8 that mandates the use of spaces, and popular opinion that
says make is crazy for using tabs.

So, I bite my lip, stop using broken tools that make dealing with space-
indents painful, and just deal with it. And you know what? It's not so
bad after all.

This is Python's most noticable blemish outside of the community.
Everybody knows that Python is the language that forces you to use a
particular style of formatting; and, that is a turn-off for many people.

Their loss. I don't miss the flame wars over the One True Brace Style.
There are enough disagreements over coding conventions without adding to
them.

It is a big mistake that whenever the issue arises, the community
effectively attacks anybody who might have disagreements with the
tradeoffs made for the Python language. This tends to set people on the
defensive and gives them a bad taste about the language as a whole.

That's very insightful. Why don't you apply some of that insight to the
other side? It is *incredibly* annoying to see the same old people making
the same old snide remarks about the same old issues over and over again,
particularly when:

* it's not an issue for thousands of other users;
* even if it were an issue, if you use the right tool for the job, the
issue disappears;
* and even if there is no right tool for the job, the feature isn't going
to change;
* and even if it would change, the people doing the whinging aren't going
to volunteer to make the change.

It would be much better if the community would simply acknowledge that
this is a tradeoff the the language has made and one which is often
misunderstood by many first time Python programmers.

Been there, done that. This is *old news*.

 

[Steven D'Aprano]

But other languages don’t make those “salient bits of syntax†invisible.
I.e. they are actually “salientâ€.

(1) Indentation is visible. Compare:


This line has leading visible whitespace.

This line has leading invisible characters.

See the difference?


(2) Salient doesn't mean visible. It means "prominent, conspicuous,
noticeable". Something can be conspicuous by its absence; conspicuous
whitespace can be
very noticeable.

 

[Grant Edwards]

Really? I have never seen bugs in C related to indentation. I have
seen plenty related to braces.

Same here.

What I have seen is bugs hidden by the indentation not matching the
block structure. Wrong indentation in Python *is* a bug. There's no
other visual signal to hide the error.

Exactly.

 

[Grant Edwards]

The difference between tabs and spaces is invisible on a great
number of the devices on which people display code.

Allowing a mixture of tabs/spaces for indentation was a mistake, and
pretty much everybody agrees on that. However, that isn't what's
being discussed.

 

[Tim Harig]

Really? I'm not aware of *any* language that promotes tabs over spaces. I
thought the tabs vs spaces war was mostly won by spaces over a decade ago
(apart from a few plucky freedom fighters who will never surrender).

Python is the only language that I know that *needs* to specify tabs versus
spaces since it is the only language I know of which uses whitespace
formating as part of its syntax and structure. Mixed usage may be annoying
in other languages; but, it breaks Python.

Otherwise, it is my experience that the preference for tabs versus spaces
depends on the users chosen platform. *nix users prefer tabs while Windows
users prefer spaces.

Actually I agree with you about tabs. I think tabs are far more logical
and sensible. But I'm stuck with broken tools that don't deal with tabs,

Where you not the one a few posts back telling Seebs that he needed to
change his broken tools?

and with PEP 8 that mandates the use of spaces, and popular opinion that
says make is crazy for using tabs.

Stupid rules are meant to be broken.

So, I bite my lip, stop using broken tools that make dealing with space-
indents painful, and just deal with it. And you know what? It's not so
bad after all.

If I am using somebody elses project, then I will post my output using
their code conventions. I have smart conversion scripts that convert
between different indent formats. I edit in the format that I prefer and,
in my projects, the indentation in the SCM is in my preferred format.

Their loss. I don't miss the flame wars over the One True Brace Style.
There are enough disagreements over coding conventions without adding to
them.

This choice has obviously not been effective in stopping flame wars. I can
cite multiple threads where it has caused them.

That's very insightful. Why don't you apply some of that insight to the
other side? It is *incredibly* annoying to see the same old people making
the same old snide remarks about the same old issues over and over again,
particularly when:

A large part of the reason that the issue keeps coming up is that the
community never really deals with it when it does. I have enough customer
support experience to know that a client is never really satisfied until
you acknowledge their problem. Until the problem is acknowledged, the
client will have put up psychological communcation block that prevents
them from hearing any workarounds that you might have.

The community never acknowledges the problem. It simply sweeps the
problem under the rug telling the people raising these issues that they
don't know what they are talking about; strengthening the psychological
block and further impeding the communication. The people with these
problems therefore never feel that they have been heard, become unwilling
to listen to the solutions, and will thus keep bringing the problem
back up.

* it's not an issue for thousands of other users;

You are now hearing the testimony of those who have had problems. I also
know that it is human nature for advocates to simply overlook the problems
when they arise. That doesn't mean that the problem is there.

I have used Python for over a decade in spite of its problems because I
believe that the benefits outway the detriments. I am however objective
enough to be congnizant of the problems; and, I am fully aware of there
effects on new members of the community.

When prospective Python programmers approach me with these problems I:

1. Acknowledge that the problem exits.

2. Explain the trade-offs that have lead to the problem.

3. Suggest ways to work around the problem.

4. Point out why I believe the benefits of using Python outway its
idiosyncrasies.

I don't just tell them that there is no problem or that the problems they
may be experiencing are their fault because they choose to do something
differently then I might.

* even if it were an issue, if you use the right tool for the job, the
issue disappears;

That a tools is needed is in itself an indication that the problem exists.
That isn't to say that good tools don't have their place or that they
cannot contribute to the solution.

* and even if it would change, the people doing the whinging aren't going
to volunteer to make the change.

Funny that. I *do* have a history of submitting patches to open source
projects.

Been there, done that. This is *old news*.

Except that you are not. Your general attitude is that since you don't
experience problems nobody else must either.

 

[Steven D'Aprano]

Sure, but there's also no way for you to spot that something looks
suspicious. In Python, if something is misindented, it does what you
told it to do, and there's no way for you to tell, by looking at it,
that it isn't what was intended. In C, if something is misindented, it
does what you told it to do, but it's obvious looking at the code that
something went wrong.

If it's that obvious, why do people keep causing those indentation-
related bugs in C?

I'm glad for you that you have a finely trained attention to detail that
is able to instantly spot misindented C code (or is that misplaced braces
and correctly indented?), but it is a notoriously common error which
suggests that it's not anywhere near as obvious as you think.

It's *far* more common than Python code being misindented.

There's even a commonly suggested style for C programmers: always use
braces any time the syntax allows them, even when they're not needed,
because the next guy who maintains the file may not be as careful and may
forget to add the braces when needed.

This level of dogmatism about what should always be the case is not
conducive to good software engineering practices.

I question that assertion. Good engineering practices is about setting
best practices, and following them, not avoiding them because there might
be the odd exception here and there.

It is not obvious to me that it's *always* the case.

So what if there is an exception one time in twenty thousand? You don't
design a tool (such as a programming language) on the basis of what's
good for the rare exceptional cases, but on what's good for the common
cases. The common case is that functions and methods should be short
enough to see the structure by eye. If it isn't, you have more problems
than just the lack of begin/end markers. The language shouldn't make
everyone carry the burden of supporting two-page functions all the time,
just to save you an insignificant amount of trouble on the vanishingly
rare occasion you need a function that is two pages long.

 

[Emile van Sebille]

On 11/3/2010 11:49 AM Tim Harig said...

A large part of the reason that the issue keeps coming up is that the
community never really deals with it when it does. I have enough customer
support experience to know that a client is never really satisfied until
you acknowledge their problem.

Then you likely also have enough experience to know that once the
customer has made the decision you accept their call. As a consultant
you move on after having done your duty bringing the issue to light.
The same applies here -- it's not changing, so you (generic you) accept
it and move on. The community has dealt with the issue by acknowledging
that differing opinions exist and the BDFL makes the final call, which
is certainly something the community accepts. I imagine a PEP could be
submitted suggesting change, and it hasn't been done because the outcome
is certain.

Otherwise, there's always whython...

http://writeonly.wordpress.com/2010/04/01/whython-python-for-people-who-hate-whitespace/

Emile

 

[Steven D'Aprano]

Where you not the one a few posts back telling Seebs that he needed to
change his broken tools?

Yes, and I also said that I sympathized with him if he couldn't.

A large part of the reason that the issue keeps coming up is that the
community never really deals with it when it does.

No. The community does deal with it. It deals with it by saying "It isn't
going to change." If you want a language that forces you to wrap ever
block in BEGIN END tags, you have a thousand choices. Python is not one
of them. What is so hard to understand about this?

I have enough
customer support experience to know that a client is never really
satisfied until you acknowledge their problem. Until the problem is
acknowledged, the client will have put up psychological communcation
block that prevents them from hearing any workarounds that you might
have.

Yes, well that too goes both ways. *I* have a psychological communication
block that prevents me from hearing any complaints about the lack of
braces from people who refuse to acknowledge that having to type braces
is stupid and annoying, and that the use of braces in a language hurts
readability.

Frankly, I DON'T CARE how often your editor breaks your source code. I
don't care about Seeb's mail server that converts his Python code to
HTML. I don't give a rat's arse about how many times some buggy ftp
client has mangled the indentation on Python files. Not my problem. Your
pain is not my pain, and any solution to these problems that involves
changing the way I read and write Python code is an anti-solution to a
non-problem to me.

Until the "Python is broken 'cos it has no braces" crowd acknowledge this
fact, I just harden my heart against their complaints. Why should *I*
have to acknowledge their issues when they don't acknowledge mine?

 

[Steven D'Aprano]

Whitespace damage is, indeed, wrong. It's a bad thing. It is an
*extremely common* bad thing,

I question that.

You've claimed that you have to deal with broken indentation on a regular
basis. I've *never* had to deal with broken whitespace, except for
certain websites that mangle leading whitespace when you post a comment.
So I don't post code on those websites.

and I fundamentally don't think it was a
good choice to build a system with no redundancy against it.

Python does have some redundancy against indentation mangling. Not all
combinations of indentation are legal.

# Not legal:
y = x + 1
z = x*y

# Not legal:
if x:
do_something()

# Not legal:
if x: do something()
else:
do_something_else()


And so on. True, there are some failure modes which can't be easily
recovered from without reading and understanding the code. That's okay.
Such failure modes are vanishingly rare -- for every twenty thousand
braces you avoid typing, you might, if you're unlucky, need to fix an
instance of broken indentation.

That
"redundant" information saves our hides on a regular basis in an
imperfect world.

So you say.

 

[Seebs]

Yes.

I'm not aware of *any* language that promotes tabs over spaces.
Makefiles.

I
thought the tabs vs spaces war was mostly won by spaces over a decade ago
(apart from a few plucky freedom fighters who will never surrender).

No. However, you've got a fallacy of the excluded middle here -- you're
ignoring the very large set of "doesn't care either way", and looking only
at things that prefer one or the other.

So, I bite my lip, stop using broken tools that make dealing with space-
indents painful, and just deal with it. And you know what? It's not so
bad after all.

I don't consider it broken for a tool to favor a more logical style which
is *actually* required by at least one format, and not a problem for anything
I've ever used except (sort of) Python.

In fact, Python works perfectly with tabs; it's just other Python
programmers who get fussy.

Their loss. I don't miss the flame wars over the One True Brace Style.
There are enough disagreements over coding conventions without adding to
them.

I don't miss them, or care about them; after all, I can just run indent/cb
to format something however I like, and run it again to match any given
coding style standard. Problem solved.

* it's not an issue for thousands of other users;

This is a non-argument. That something isn't a problem for other people
makes no difference to the people for whom it's a problem.

* even if it were an issue, if you use the right tool for the job, the
issue disappears;

I have never found any other editor that I like as much as the one I use
now.

* and even if there is no right tool for the job, the feature isn't going
to change;

I think you miss the point of the observation. I'm not expecting it to
change; I'm pointing out that insisting that it's not a problem is
*insulting* to the people for whom it is a problem.

* and even if it would change, the people doing the whinging aren't going
to volunteer to make the change.

Oh, I'd happily contribute code if it'd matter. But it wouldn't.

Been there, done that. This is *old news*.

I haven't seen it done yet. I've seen a whole lot of people tell me that
an editor I've been using for twenty years is "broken" because I found
a program that is brittle with regards to its inputs that is prone to
being triggered by a behavior which has been free of problems (and indeed
in some cases *mandatory*) for everything else. I've seen people smugly
tell me that I'd love this if I just tried it. That didn't work for
pickles, it didn't work for Player-vs-Player fighting in video games,
and it's not gonna work for the lack of end markers.

Explicit is better than implicit.

-s