Compare source code

[Grant Edwards]

And how does that affect a Python program? The same as it does a C
program.

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.

Different line-endings are tolerated by Python just as well as they
are by C.

 

[Tim Harig]

You totally misunderstand me. I am not on a crusade of any sort. I am

I appologize that I confused your name with Steven D'Aprano; but, your
positions are pretty much the same.

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.

Neither of you are really adding anything to the conversation other then to
assert that you like whitespace syntax and that the problems do not effect
you. Good for you; but, that doesn't help the people who are finding that
it presents problems.

I might if it was a problem for me.

Good for you but telling us that doesn't really help those that do. Your
stance is based an a stylistic preference. Holy wars around style continue
to exist because, in most cases, it is almost impossible to prove the
advantages of one reasonable style over another.

It is, however, verifiable that white space syntax causes issues with a
large number of common tools. I am a man of science. When choosing
between the intangible and verifiable, I choose the verifable truth.

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.

It is simply hard for me to accept that your solution is better when
it is telling us that we have to abandon thousands of tools that other
solutions manage to work with without difficulty.

 

[Tim Harig]

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.

Thank-you for your tip. It is nice to know that some people are thinking
of ways to work around the trade-offs rather then just asserting that we
shouldn't use tools that happen to collide with Python.

 

[Tim Harig]

And how does that affect a Python program? The same as it does a C
program.

I wasn't making any statement of C versus Python in this thread. Those
have been covered elsewhere. I was responding to your assertion:

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.

That is clearly wrong. If a C programmer changes the format of the code,
it is almost universally true that they will make changes that affect more
then just the whitespace on a single line. Diff will register these
changes even with the -b option. I provided a couple of common scenerios
that are more likely to have justified the -b option.

 

[John Nagle]

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

Not magic, just code understanding.

INTERLISP's editor allowed the user to select a block of
LISP code and make it into a function. The selected block
would be analyzed to determine which local variables it referenced,
and a new function would be created with those parameters. The
block of code at the original point would then be replaced by
a call to the function.

Today's editors are too dumb to do that right. They're text
editors with the illusion of knowing something about the language,
not language editors which also format text.

John Nagle

 

[Emile van Sebille]

On 11/5/2010 11:13 AM Tim Harig said...

It is simply hard for me to accept that your solution is better when
it is telling us that we have to abandon thousands of tools that other
solutions manage to work with without difficulty.

I only work with a few tools none of which alter or strip leading
whitespace, and I don't try to transport python code in ways that allow
harmful transformations to take place, eg, reinterpreted by html or
email rendering engines, which aren't effective programming tools anyway.

So, which of your tools are you married to that are causing your issues?

If-you-got-a-bigger-hammer-you-could-drive-that-phillips-screw-into-anything-ly
y'rs,

Emile

 

[Seebs]

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

I would love to know the answer to this question.

However, empirically, it happens.

My guess would be cutting and pasting in some way.

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

To some extent, this is true.

How about this. How about we make the Python TCP Stack. The Python TCP
Stack works on the same principles that you advocate for the Python
language. For instance, if any packet it receives is malformed or
contrary to the applicable specs, it has a 95% chance of dropping the packet,
and a 5% chance of interpreting the packet as being of a different type
entirely.

This will NEVER be a problem, and is a good design, because handling
packets which contain any kind of spec violation is just work-arounds
for broken tools, right?

And the first thing we should do is *always* to ensure that, if anything
anywhere does not live up to our proposed specification, it causes us to
fail in spectacular ways.

Of course, to fully capture the feel of Python's choice here, we have
to include some common packet variant, which violates no RFCs, as
one of the "broken" ones on the grounds that it doesn't make sense to
us and isn't easy for a newcomer to read.

-s

 

[Seebs]

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

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.

There was no magic auto-reformat. Where did you invent that from? Why are
you making stuff up which I never said or referred to?

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.

No, I am not. No such tool was involved. I never mentioned one, referred
to one, or hinted at one -- and have never used one, because I hate them.
In fact, it is ludicrous to imagine that I was using one, given that I've
stated in this very thread that so far as I know such a tool cannot
be created for Python.

Your decision to invent something I never referred to is not a problem with
my approach to the language.

-s

 

[Seebs]

So, which of your tools are you married to that are causing your issues?

Python.

-s

 

[Grant Edwards]

Python.

I think you should quit using Python and choose a language that works
with whatever tools are causing all your white-space corruption
problems.

 

[D'Arcy J.M. Cain]

Neither of you are really adding anything to the conversation other then to

Well, whether I am adding anything is a judgement call. That I don't
accept your premise doesn't mean that my postings are content free.

It is, however, verifiable that white space syntax causes issues with a
large number of common tools. I am a man of science. When choosing

The simple fact is that the combination of your tools and Python is
broken. The combination of my tools and Python is not. That's lucky
for me since I really, really like IAS. That's unlucky for people who
have to work with tools that mangle code. But don't crusade to change
my language. Use Perl or C or even pybraces.

It is simply hard for me to accept that your solution is better when
it is telling us that we have to abandon thousands of tools that other
solutions manage to work with without difficulty.

I am offering no solutions. Why would I since I don't see a problem?

 

[Ethan Furman]

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.

The verifiable benefit for me is ease of use, ease of thought, ease of
typing... I realize these are not benefits for everyone, but they are
for some -- and I would venture a guess that the ease of thought benefit
is one of the primary reasons Python is popular. I am definitely one of
those that think indentation based structure is one of Python's best
features.

I do acknowledge that if you don't think that way, it can be major
hassle, and I sympathize.

~Ethan~

 

[Ian]

    INTERLISP's editor allowed the user to select a block of
LISP code and make it into a function.  The selected block
would be analyzed to determine which local variables it referenced,
and a new function would be created with those parameters.  The
block of code at the original point would then be replaced by
a call to the function.

    Today's editors are too dumb to do that right.  They're text
editors with the illusion of knowing something about the language,
not language editors which also format text.

Eclipse does that. Visual Studio does that. As for Python, I hear
that Eric IDE has a plugin to do that, although I haven't tested it
myself.

Cheers,
Ian

 

[Seebs]

I think you should quit using Python and choose a language that works
with whatever tools are causing all your white-space corruption
problems.

Ahh, but that's the thing. I'm married to it -- there's existing projects
I want to work on which are in Python.

Anyway, it was a sort of frivolous answer, but it's ha-ha-only-serious;
after all, there were no serious issues with any of these tools before.

There's a saying a friend of mine has; "a lack of communication is never
exclusively one party's fault." This applies, in many cases, to things
like "issues" that occur when two programs clash in some aspect of their
designs. In some cases, there might be a real and unambiguous standard
to be violated. In others, though, you can have a problem which arises
from a clash in expectations between two programs, either of which is fine
on its own.

There is a clash between Python and the whole category of things which
sometimes lose whitespace. Because that category is reasonably large,
and known to be large, and unlikely to vanish, many language designers
choose to build their languages to be robust in the face of minor changes
in whitespace. Python chose not to, and that is a source of conflicts.

Were someone to invent a *new* text editor, which mangled whitespace, I
would accuse it of being gratuitously incompatible with Python; I tend
to regard compatibility, once you get past the standards, as a matter
of temporal precedence.

-s

 

[Seebs]

The verifiable benefit for me is ease of use, ease of thought, ease of
typing... I realize these are not benefits for everyone, but they are
for some -- and I would venture a guess that the ease of thought benefit
is one of the primary reasons Python is popular. I am definitely one of
those that think indentation based structure is one of Python's best
features.

Could you explain more the "ease of thought" thing? I haven't yet noticed
it, but it might be something to look out for as I get more experienced.

It certainly sounds like something that would be a benefit.

-s

 

[Seebs]

The simple fact is that the combination of your tools and Python is
broken. The combination of my tools and Python is not. That's lucky
for me since I really, really like IAS. That's unlucky for people who
have to work with tools that mangle code. But don't crusade to change
my language. Use Perl or C or even pybraces.

No one is crusading to change Python, or even suggesting that it should
be changed.

I am offering no solutions. Why would I since I don't see a problem?

One of the things many people try to do is develop the ability to "see"
problems that affect other people but possibly not themselves. This allows
people to offer solutions to those problems, which is often viewed as
a kind of contribution to a community. Certainly, it's more useful than
posting nothing more than "that's not a problem for me."

I can just see how well this attitude must work in other circumstances:
Some Guy: Oh, *!@#. I think I just sprained my ankle.

Darcy: I didn't.

Some Guy: I don't think I can walk up these stairs.

Darcy: I don't have a problem with stairs. Stop trying to
change this path. It works fine.

-s

 

[Terry Reedy]

my language. Use Perl or C or even pybraces.

http://timhatch.com/projects/pybraces/
"I work with a guy who hates Python's significant whitespace and wishes
that he could just use curly braces."

I am offering no solutions.

Except you just did ;-).
And using a braces encoding makes
it looks easier than I expected.

 

[D'Arcy J.M. Cain]

I can just see how well this attitude must work in other circumstances:

I guess this message ends the topic for me. Bye.

 

[Steven D'Aprano]

Examples of communication channels that mangle white space abound.

Yes. So what? If your communication channel mangles your data, change
your communication channel, don't expect users of clean communication
channels to hand-enter error-correcting codes (braces) into the data.

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.

Why is it the responsibility of the programming language syntax to
correct the problem with Seebs' faulty mail server?

I've experienced the spilled-coke-on-the-keyboard problem more often than
mangled whitespace, but you don't see me arguing that what every language
needs is error-correcting codes that let me work with keyboards that have
had Coke spilled on them.


[...]

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.

Okay, now you have zero credibility.

XML is not a data format for human use, it is for use by machines. It is
slow, inefficient, and uneditable by humans except for the most trivial
cases.

 

[Steven D'Aprano]

[...]
I am also aware of other langauges such as Boo; but, I don't really
consider them individually relevant to the conversation as they are
explicitly using a Python based syntax. For this discussion I merely
group them with Python.

You might as well say that C is the only language that uses tags around
blocks, since for this discussion "I merely group" Pascal, Algol, Java,
etc with C.