Compare source code

[Grant Edwards]

True, but diff doesn't come with an "ignore curly braces" option.

True, but the fact that diff has an option that for Python sources
will produces useless results doesn't seem like a valid indictment of
Python's syntax and semantics.

I'm not personally repelled by Python's use of significant
indentation, but I must concede that some awkwardness results from
assigning significance to something (whitespace) that many tools are
inclined to treat as insignificant.

However, the human brain does treat whitespace as significant.

 

[Grant Edwards]

Right.

But there's no *reason* to do that, while there are many common daily
events which result in whitespace changes. e.g., any email sent to
my work account is being magically transformed into HTML (no one
knows why) on the server, so I can't get correct indentation except
in attachments.

And you think compatibility with your broken e-mail server is a good
reason to change the syntax of a programming language?

Many editors helpfully convert spaces to tabs by default some or all
of the time. And so on.

Such editors are broken.

The more I use it, the more I think it was an interesting experiment
which has worked out about as well as scanf.

I think it's brilliant (indentation that actually means something, not
scanf).

The "problem" it fixes is something that's hardly ever been a problem
for me in C or related languages -- and which could be completely
eliminated by automated indenters, which were actually conceptually
possible.

They're only possible if you put redundant block markers in the
source.

I've lost more time to indentation issues in Python in a month than
I've lost to mismatches between indentation and flow in C in twenty
years.

Then you're doing something terribly wrong. I find indentation-based
structure to be completely effortless. Are you using an editor that
doesn't have a Python mode?

In theory, it sounds like it would help to eliminate the ambiguity.
In practice, eliminating the question of whether code was intended to
follow explicit flow rather than indentation just means that when
there's a mistake you don't even get a warning that someone was
confused.

At least in C, if I see:
if (foo)
a;
else
b;
c;

I *know* that something is wrong.

I suppose you can add comments to Python if you some syntactically
null "redudundacy" to indicate the intended structure. Personally,

 

[Grant Edwards]

Ah, but other languages don't make the guarantee that you can add or
remove random whitespace in arbitrary places and still have code that
works correctly!

Of course, neither does Python, but there's a certain type of
personality that is never happy unless they are bitching and moaning,
and if they can't find something more substantial to bitch and moan
about, they'll bitch and moan about the fact that they can't make
random changes to syntactically significant tokens in their source
code without things breaking. Boo hoo, cry me a river.


Personally, I'm more disturbed by the default prompt in the
interactive interpreter. >>> clashes with the symbol used for quoting
text in email and news. That causes me far more distress than
indentation.

I've tripped over that as well. Not very often, but it's a bigger
problem than significant whitespace. I must admit that the first few
minutes I worked with Python having significant whitespace seemed
awkward -- probably because it invoked unpleasant memories of Fortran
IV on punch-cards.

After a short time, I suddenly realized that Python got it right: the
compiler and my brain are using the _same_thing_ to denote program
structure. All those years of my brain using one thing and the
compiler using a different thing were (and are) obviously the wrong
way to do it.

 

[Seebs]

You have problems. Indentation as syntax isn't one of them.

In the absence of indentation as syntax, they haven't bugged me.

"No one
knows why" email is being "magically" transformed?

Yay for a large company IT department with both MS and Blackberry
stuff involved.

Your editor has a
mind of its own? Yikes!

It is extremely useful to me to have spaces converted to tabs
for every other file I edit.

Your experience is 180 from mine.

Could be. But really, I've simply never seen a real problem with
flow/indentation mismatches in C.

Does it look right? With Python looking right and being right are the
same thing.

No, they aren't. See... That would work *if I knew for sure what the intent
was*.

if foo:
bar
else:
baz
quux

Does it look right? We have *no idea*, because we don't actually know
whether quux was *intended* to be in the else branch or whether that's a typo.

So the only way I can figure that out is by fully figuring out the function
of all the code bits -- meaning I have to fully understand the code, same
as I would to debug the C. The fact that indentation is flow control
just means I have only one set of cues, so I can't watch for mismatches.

-s

 

[Seebs]

I've lost more time to reading people's bitching about indentation than I
have dealing with indentation problems.

Doesn't totally surprise me.

But then, I don't insist on using tools which are broken by design.

Neither do I.

If your email server converts plain text to HTML, it is broken.

Yup. I have an open ticket with the IT department.

If your
editor changes spaces to tabs, or visa versa, without being told to do so
(either by an explicit command or an obvious setting), then your editor
is broken.

Yes. But that's the thing -- I *want* that behavior for every other tool,
file format, or other thing I work with.

If you are stuck with broken mail servers and broken editors and broken
tools because of political reasons, then you have my sympathy. But stop
insisting that everybody has to carry the overhead of your work-arounds
for your broken tools.

I have made no such insistance. I have not said Python should change. I
have not said other people should want what I want. I'm not the one telling
other people that editors they've used happily for twenty years without
any problems are clearly wrong.

I have merely observed that Python is, in this respect, gratuitously
brittle. It doesn't observe the robustness principle; it is
conservative in what it accepts, and in particular, is vulnerable to a
category of problem which is fairly common, well-known, and likely to
remain common for the next few decades.

There are reasons for it to be this way, and I don't object to the
existence of people who prefer that side of the tradeoff. I do dislike
it when people smugly tell me off for having different preferences.

-s

 

[Grant Edwards]

In the absence of indentation as syntax, they haven't bugged me.


Yay for a large company IT department with both MS and Blackberry
stuff involved.


It is extremely useful to me to have spaces converted to tabs
for every other file I edit.



Could be. But really, I've simply never seen a real problem with
flow/indentation mismatches in C.



No, they aren't. See... That would work *if I knew for sure what the intent
was*.

if foo:
bar
else:
baz
quux

Does it look right? We have *no idea*, because we don't actually know
whether quux was *intended* to be in the else branch or whether that's a typo.

So the only way I can figure that out is by fully figuring out the function
of all the code bits -- meaning I have to fully understand the code, same
as I would to debug the C. The fact that indentation is flow control
just means I have only one set of cues, so I can't watch for mismatches.

You can add redundant, semantically empty structure info to Python
programs just as easily as you can to C programs:

if foo:
bar
else:
baz
quux
#endif

 

[Emile van Sebille]

On 11/2/2010 10:58 AM Seebs said...

No, they aren't. See... That would work *if I knew for sure what the intent
was*.

if foo:
bar
else:
baz
quux

Does it look right? We have *no idea*, because we don't actually know
whether quux was *intended* to be in the else branch or whether that's a typo.

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)

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.

Whether that's what the specs called for or not is always a source for bugs.

Emile

 

[Grant Edwards]

On 11/2/2010 10:58 AM Seebs said...

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)

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.

Whether that's what the specs called for or not is always a source
for bugs.

Yup. I've never found that the ability to write incorrect code that
_appears_ correct to be a good thing. Nor do I find the ability to
write correct code that appears to be incorrect to be valuable.

In Python, if the structure looks right, then structure _is_ right.

 

[D'Arcy J.M. Cain]

Yay for a large company IT department with both MS and Blackberry
stuff involved.

"Large" is no excuse for incompetency.

It is extremely useful to me to have spaces converted to tabs
for every other file I edit.

So configure it to recognize Python files and act accordingly.

No, they aren't. See... That would work *if I knew for sure what the intent
was*.

if foo:
bar
else:
baz
quux

Does it look right? We have *no idea*, because we don't actually know
whether quux was *intended* to be in the else branch or whether that's a typo.

And C has the same problem.

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".

So the only way I can figure that out is by fully figuring out the function

Same is true for the C code. 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.

In either case, <syntax checker> != <debugger>.

 

[D'Arcy J.M. Cain]

You can add redundant, semantically empty structure info to Python
programs just as easily as you can to C programs:

if foo:
bar
else:
baz
quux
#endif

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

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

Useful in more complicated code, of course.

 

[Ethan Furman]

Personally, I'm more disturbed by the default prompt in the interactive
interpreter. >>> clashes with the symbol used for quoting text in email
and news. That causes me far more distress than indentation.

Here here!

I finally did "sys.ps1 = '--> '" in my interactive startup file.

~Ethan~

 

[Seebs]

True, but the fact that diff has an option that for Python sources
will produces useless results doesn't seem like a valid indictment of
Python's syntax and semantics.

The question is *why* diff has that option.

The answer is because whitespace changes (spaces to tabs, different
tab stops, etcetera) are an extremely common failure mode, such that
it's quite common for files to end up with unintentional whitespace
changes.

This, in turn, is why there are so many tools to automatically fix up
whitespace type issues, such as cb/indent for C, auto-indentation for
many languages (including stuff like XML) features in editors, and so
on -- because it's a common problem.

-s

 

[Tim Harig]

Yes. But that's the thing -- I *want* that behavior for every other tool,
file format, or other thing I work with.

I agree with Seebs, Python is the only language I know that promotes
the use of spaces over tabs; 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.

I have made no such insistance. I have not said Python should change. I
have not said other people should want what I want. I'm not the one telling
other people that editors they've used happily for twenty years without
any problems are clearly wrong.

Indeed, a simple script is enough to identify how levels are indented and
convert the present indenting to whatever is your preference.

There are reasons for it to be this way, and I don't object to the
existence of people who prefer that side of the tradeoff. I do dislike
it when people smugly tell me off for having different preferences.

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.
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.

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.

 

[Seebs]

And you think compatibility with your broken e-mail server is a good
reason to change the syntax of a programming language?

No. I never said that.

Such editors are broken.

If I use an editor for twenty years, and it works beautifully with fifteen
different programming languages across five operating systems, and someone
comes along with a file format which tends to silently break when treated
the same way, my first response is not to blame the editor.

I think it's brilliant (indentation that actually means something, not
scanf).

It is. However, it's also brittle.

They're only possible if you put redundant block markers in the
source.

Yes. Or make the block markers not-redundant.

Then you're doing something terribly wrong. I find indentation-based
structure to be completely effortless.

And it is *ABSOLUTELY CERTAIN* that, if any two people have different
experiences of how easy or hard something is, it's because one of them
is doing something wrong, right?

Because people are *never* actually different. There is no such thing
as "preferences". There is no such thing as a "matter of taste". No,
no. If one person finds something comfortable, and another dislikes it,
it's because the second one is *doing something terribly wrong*.

Are you using an editor that
doesn't have a Python mode?

Yes. I haven't used "modes" in editors until now. I've never needed to.
Every other file format I work with is robust about this.

-s

 

[rustom]

Sigh! How flame-wars tend to lose the original question:

Hi,

I've a project with tabs and spaces mixed (yes I know it's bad).

Do python aficionados want to suggest that mixing spaces and tabs is a
'good thing'?

 

[Grant Edwards]

Here here!

I finally did "sys.ps1 = '--> '" in my interactive startup file.

So _now_ what are going to whinge about?

 

[Ethan Furman]

So _now_ what are going to whinge about?

^-
\
missing a word?

If the word is "you" -- how about complaints about the documentation?

elif the word is "we" -- maybe lack of reading comprehension?

elif the word is "Steven" -- absolutely no clue

else -- maybe multiple inheritance being a bug...
http://bugs.python.org/issue2667

~Ethan~

 

[Lawrence D'Oliveiro]

On 11/1/2010 4:22 PM Lawrence D'Oliveiro said...


But it does so by intent. Other languages lend only an appearance of
structure through the indentation style of the writer.

No, the indentation is there to make the structure clearer, not to act as a
substitute for the structure. Try to conflate the two, and you end up with
problems such as we are discussing.

It's as good as outdated comments.

Outdated comments are a bug like any other, and should be fixed.

 

[Lawrence D'Oliveiro]

Why?

Other languages have similar problems if you remove salient bits of
syntax before comparing two source files files.

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

 

[Grant Edwards]

But other languages don???t make those ???salient bits of syntax???
invisible.

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

I'm baffled...