Compare source code
jf
I've a project with tabs and spaces mixed (yes I know it's bad).
I edit each file to remove tabs, but it's so easy to make a mistake.
Do you know a tools to compare the initial file with the cleaned one to
know if the algorithms are the same ?
By comparing pyc files for example.
Thanks.
Martin v. Loewis
Tools/scripts/reindent.py of the standard Python distribution normalizes
white space in source code. It is used to maintain normalized
indentation in the Python library itself, but you can certainly use it
also for your own files :-)
Regards,
Martin
jf
>> I've a project with tabs and spaces mixed (yes I know it's bad).
>>
>> I edit each file to remove tabs, but it's so easy to make a mistake.
>> Do you know a tools to compare the initial file with the cleaned one to
>> know if the algorithms are the same ?
>
> white space in source code.
So great, you save my time !
Should I be worry about this comment in reindent.py "So long as the
input files get a clean bill of health from tabnanny.py, reindent should
do a good job." ?
Thanks
Martin v. Loewis
> input files get a clean bill of health from tabnanny.py, reindent should
> do a good job." ?
I don't think so: IIUC, this is about comments that are not reasonably
aligned with preceding or following code lines, most likely, you don't
have such comments in your files.
Regards,
Martin
Lawrence D'Oliveiro
> I edit each file to remove tabs ...
expand -i <oldfile >newfile
> Do you know a tools to compare the initial file with the cleaned one to
> know if the algorithms are the same ?
diff -b oldfile newfile
Bob Martin
meld
Peter Pearson
Warning: "diff -b" won't detect changes in indentation. Changes in
indentation can change a Python program.
--
To email me, substitute nowhere->spamcop, invalid->net.
Lawrence D'Oliveiro
> On Mon, 01 Nov 2010 12:09:12 +1300, Lawrence D'Oliveiro wrote:
>
>> In message <4ccd5ad9$0$19151$426a...@news.free.fr>, jf wrote:
>>
>>> I edit each file to remove tabs ...
>>
>> expand -i <oldfile >newfile
>>
>>> Do you know a tools to compare the initial file with the cleaned one to
>>> know if the algorithms are the same ?
>>
>> diff -b oldfile newfile
>
> Warning: "diff -b" won't detect changes in indentation. Changes in
> indentation can change a Python program.
I’m getting less and less keen on that particular feature of Python...
Grant Edwards
Why?
Other languages have similar problems if you remove salient bits of
syntax before comparing two source files files.
For exmaple, if you remove all of the curly-braces from two C source
files before comparing them, you don't get useful results.
--
Grant Edwards grant.b.edwards Yow! I'm continually AMAZED
at at th'breathtaking effects
gmail.com of WIND EROSION!!
Peter Pearson
> On 2010-11-01, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:
>> In message <8j8am4...@mid.individual.net>, Peter Pearson wrote:
>>>
>>>> diff -b oldfile newfile
>>>
>>> Warning: "diff -b" won't detect changes in indentation. Changes in
>>> indentation can change a Python program.
>>
>> I'm getting less and less keen on that particular feature of Python...
>
> Why?
>
> Other languages have similar problems if you remove salient bits of
> syntax before comparing two source files files.
>
> For exmaple, if you remove all of the curly-braces from two C source
> files before comparing them, you don't get useful results.
True, but diff doesn't come with an "ignore curly braces" option.
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.
Emile van Sebille
>> Warning: "diff -b" won't detect changes in indentation. Changes in
>> indentation can change a Python program.
>
> I’m getting less and less keen on that particular feature of Python...
That feature being indentation based structure? At least you can look
at python code and _know_ that spurious placement of required line noise
don't have the ability to impact what the code does.
Emile
Lawrence D'Oliveiro
Sebille wrote:
> At least you can look at python code and _know_ that spurious placement of
> required line noise don't have the ability to impact what the code does.
But it does. What is spurious whitespace if not noise, after all?
Ian
> True, but diff doesn't come with an "ignore curly braces" option.
> 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.
Beyond Compare at least is smart enough to know that leading
whitespace is significant in .py files, using the default
configuration.
Cheers,
Ian
Seebs
> On 2010-11-01, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:
>> In message <8j8am4...@mid.individual.net>, Peter Pearson wrote:
>>> Warning: "diff -b" won't detect changes in indentation. Changes in
>>> indentation can change a Python program.
>> I'm getting less and less keen on that particular feature of Python...
> Why?
> Other languages have similar problems if you remove salient bits of
> syntax before comparing two source files files.
Sure.
> For exmaple, if you remove all of the curly-braces from two C source
> files before comparing them, you don't get useful results.
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. Many editors helpfully convert spaces to tabs
by default some or all of the time. And so on.
The more I use it, the more I think it was an interesting experiment
which has worked out about as well as 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.
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. 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.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
D'Arcy J.M. Cain
Seebs <usenet...@seebs.net> wrote:
> 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. Many editors helpfully convert spaces to tabs
> by default some or all of the time. And so on.
You have problems. Indentation as syntax isn't one of them. "No one
knows why" email is being "magically" transformed? Your editor has a
mind of its own? Yikes!
> 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
Your experience is 180 from mine.
> years. 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.
Does it look right? With Python looking right and being right are the
same thing. Once I realized that indentation should only be done using
spaces in Python I never had a problem. I certainly had problems with
C when the code looked right. Sometimes you can't even see the problem
because it's hidden in a badly defined macro.
--
D'Arcy J.M. Cain <da...@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
Lawrence D'Oliveiro
> At least in C, if I see:
> if (foo)
> a;
> else
> b;
> c;
>
> I *know* that something is wrong.
This is why, when I started learning Python, I soon developed the habit of
inserting explicit “#end” markers. To Pythonize your example my way, it
would have come out as
if foo :
a
else :
b
#end if
c
which should also give a hint that something might be wrong.
Steven D'Aprano
> On 2010-11-01, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand>
> wrote:
[...]
>> I'm getting less and less keen on that particular feature of Python...
>
> Why?
>
> Other languages have similar problems if you remove salient bits of
> syntax before comparing two source files files.
>
> For exmaple, if you remove all of the curly-braces from two C source
> files before comparing them, you don't get useful results.
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.
Doing a bit of my own bitching and moaning'ly y'rs,
--
Steven
Steven D'Aprano
> I must concede that some awkwardness results from assigning significance
> to something (whitespace) that many tools are inclined to treat as
> insignificant.
Then the tools are broken.
Or perhaps I should say:
Th enth etool sarebroke n.
--
Steven
Steven D'Aprano
> 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.
I suppose then you're going to insist that Python should stop using > and
< for comparison operators, because your mail server converts them to
> and < escapes?
> 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.
I've lost more time to reading people's bitching about indentation than I
have dealing with indentation problems.
But then, I don't insist on using tools which are broken by design. If
your email server converts plain text to HTML, it is broken. 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.
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.
--
Steven
Emile van Sebille
But it does so by intent. Other languages lend only an appearance of
structure through the indentation style of the writer. It's as good as
outdated comments.
Emile
Grant Edwards
> On Mon, 1 Nov 2010 22:24:03 +0000 (UTC), Grant Edwards wrote:
>> On 2010-11-01, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:
>>> In message <8j8am4...@mid.individual.net>, Peter Pearson wrote:
>>>>
>>>>> diff -b oldfile newfile
>>>>
>>>> Warning: "diff -b" won't detect changes in indentation. Changes in
>>>> indentation can change a Python program.
>>>
>>> I'm getting less and less keen on that particular feature of Python...
>>
>> Why?
>>
>> Other languages have similar problems if you remove salient bits of
>> syntax before comparing two source files files.
>>
>> For exmaple, if you remove all of the curly-braces from two C source
>> files before comparing them, you don't get useful results.
>
> 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 grant.b.edwards Yow! I joined scientology
at at a garage sale!!
gmail.com
Grant Edwards
> On 2010-11-01, Grant Edwards <inv...@invalid.invalid> wrote:
>> On 2010-11-01, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:
>>> I'm getting less and less keen on that particular feature of
>>> Python...
>
>> Why?
>
>> Other languages have similar problems if you remove salient bits of
>> syntax before comparing two source files files.
>
> Sure.
>
>> For exmaple, if you remove all of the curly-braces from two C source
>> files before comparing them, you don't get useful results.
>
> 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 grant.b.edwards Yow! I'm having a
at quadrophonic sensation
gmail.com of two winos alone in a
steel mill!
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.
--
Grant Edwards grant.b.edwards Yow! My BIOLOGICAL ALARM
at CLOCK just went off ... It
gmail.com has noiseless DOZE FUNCTION
and full kitchen!!
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.
>> 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
> Your experience is 180 from mine.
Could be. But really, I've simply never seen a real problem with
flow/indentation mismatches in C.
>> At least in C, if I see:
>> if (foo)
>> a;
>> else
>> b;
>> c;
>>
>> I *know* that something is wrong.
> 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.
Seebs
> 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.
Grant Edwards
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
--
Grant Edwards grant.b.edwards Yow! With YOU, I can be
at MYSELF ... We don't NEED
gmail.com Dan Rather ...
Emile van Sebille
> 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
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.
--
Grant Edwards grant.b.edwards Yow! Now we can become
at alcoholics!
gmail.com
D'Arcy J.M. Cain
Seebs <usenet...@seebs.net> wrote:
> On 2010-11-02, D'Arcy J.M. Cain <da...@druid.net> wrote:
> > "No one
> > knows why" email is being "magically" transformed?
>
> Yay for a large company IT department with both MS and Blackberry
> stuff involved.
"Large" is no excuse for incompetency.
> > 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.
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
Grant Edwards <inv...@invalid.invalid> wrote:
> 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~
Tim Harig
>> 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.
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.
>> 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.
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
> 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.
Seebs
> reason to change the syntax of a programming language?
No. I never said that.
>> Many editors helpfully convert spaces to tabs by default some or all
>> of the time. And so on.
> 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.
>> 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.
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.
rustom
On Oct 31, 5:02 pm, jf <j...@aucuneadresse.fr> wrote:
> 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
So _now_ what are going to whinge about?
--
Grant Edwards grant.b.edwards Yow! I am NOT a nut....
at
gmail.com
Ethan Furman
> On 2010-11-02, Ethan Furman <et...@stoneleaf.us> wrote:
>> Steven D'Aprano wrote:
>>> 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.
>>
>
> 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
Sebille wrote:
> On 11/1/2010 4:22 PM Lawrence D'Oliveiro said...
>
>> In message<mailman.465.1288653...@python.org>, Emile van
>> Sebille wrote:
>>
>>> At least you can look at python code and _know_ that spurious placement
>>> of required line noise don't have the ability to impact what the code
>>> does.
>>
>> But it does. What is spurious whitespace if not noise, after all?
>
> 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
> On 2010-11-01, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand>
> wrote:
>
>> In message <8j8am4...@mid.individual.net>, Peter Pearson wrote:
>>>
>>>> diff -b oldfile newfile
>>>
>>> Warning: "diff -b" won't detect changes in indentation. Changes in
>>> indentation can change a Python program.
>>
>> I'm getting less and less keen on that particular feature of Python...
>
> 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
> In message <ianem3$cuq$1...@reader1.panix.com>, Grant Edwards wrote:
>
>> On 2010-11-01, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand>
>> wrote:
>>
>>> In message <8j8am4...@mid.individual.net>, Peter Pearson wrote:
>>>>
>>>>> diff -b oldfile newfile
>>>>
>>>> Warning: "diff -b" won't detect changes in indentation. Changes in
>>>> indentation can change a Python program.
>>>
>>> I'm getting less and less keen on that particular feature of Python...
>>
>> Why?
>>
>> Other languages have similar problems if you remove salient bits of
>> syntax before comparing two source files files.
>
> invisible.
Huh? Indentation is invisible? You can't see the indentation in
Python source code?
I'm baffled...
--
Grant
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
> 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.)
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.
>> 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.
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.
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.
Seebs
> 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.
D'Arcy J.M. Cain
Tim Harig <use...@ilthio.net> wrote:
> On 2010-11-02, D'Arcy J.M. Cain <da...@druid.net> wrote:
> 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
Seebs <usenet...@seebs.net> wrote:
> 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
> On Wed, 3 Nov 2010 00:41:46 +0000 (UTC)
> Tim Harig <use...@ilthio.net> wrote:
>> On 2010-11-02, D'Arcy J.M. Cain <da...@druid.net> wrote:
>> 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.
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
> On 2010-11-03, D'Arcy J.M. Cain <da...@druid.net> wrote:
>> On Wed, 3 Nov 2010 00:41:46 +0000 (UTC)
>> Tim Harig <use...@ilthio.net> wrote:
>> 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.
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
> On 03 Nov 2010 01:20:40 GMT
> Seebs <usenet...@seebs.net> wrote:
>> 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.
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.
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
Steven D'Aprano
(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.
--
Steven
Grant Edwards
> On 03 Nov 2010 01:20:40 GMT
> Seebs <usenet...@seebs.net> wrote:
>> 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.
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 grant.b.edwards Yow! I selected E5 ... but
at I didn't hear "Sam the Sham
gmail.com and the Pharoahs"!
Grant Edwards
> On 2010-11-02, Grant Edwards <inv...@invalid.invalid> wrote:
>> 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.
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.
> 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.
--
Grant Edwards grant.b.edwards Yow! An air of FRENCH FRIES
at permeates my nostrils!!
gmail.com
Tim Harig
> On Tue, 02 Nov 2010 19:26:56 +0000, Tim Harig wrote:
>
>> 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).
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.
>> 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,
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.
>> 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.
This choice has obviously not been effective in stopping flame wars. I can
cite multiple threads where it has caused 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:
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.
>> 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*.
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.
>> 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.
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.
--
Steven
Emile van Sebille
> 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
>> 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?
Yes, and I also said that I sympathized with him if he couldn't.
>>> 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:
>
> 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
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.
--
Steven
Seebs
>> 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 don't think they do. I can't remember the last time I've seen one.
> 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 "notoriously common", but can you show me an actual example of
it happening in real code? Not a "hey guys look how misleading this
would be" example conjured up for illustration, but an *actual* example
in live code?
I can't remember one, except I think maybe I saw one somewhere in...
hmm. No, wait, that was perl.
>> 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.
I don't think I buy this. I've seen a whole lot of good writers and good
programmers, and in both groups, they consistently report that you have
to know how the rules work before you break them.
> 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.
I don't think there's a particularly big burden there.
Explicit is better than implicit. It is *better* to explicitly mark the
ends of things than to have it be implicit in dropping indentation. That's
not a burden, it's good engineering practice.
Seebs
>> 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'd guess I see something which got screwed up somehow every couple of
weeks, usually while refactoring stuff.
>> 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.
True, but it doesn't seem to catch the most common failure modes.
> 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.
This is ridiculous overstatement. Moving a single block of overly-nested
code out into a separate method could generate several indentation
mishaps if Something Goes Wrong, which it does sometimes. I haven't
written more than a couple hundred blocks in Python, so I'm a factor of a
hundred out from twenty thousand braces, and I've had six or seven
indentation problems.
And yes, I can just recreate it, but it takes more effort, since I can't
do things like just handing it to an automated tool that can correct
it completely automatically.
Furthermore, I don't WANT to skip closing braces. EXPLICIT IS BETTER
THAN IMPLICIT. I *WANT* to have the beginnings and ends marked.
I want end braces or "end" or something at the end of a block for
the same reason that I prefer:
x = "hello, world"
to
x = "hello, world
where we just assume the string ends at the end of the line.
>> That
>> "redundant" information saves our hides on a regular basis in an
>> imperfect world.
> So you say.
Well, it works for me.
Grant Edwards
> Explicit is better than implicit. It is *better* to explicitly mark the
> ends of things than to have it be implicit in dropping indentation. That's
> not a burden, it's good engineering practice.
Dededenting does explicitly mark the end of a block.
--
Grant Edwards grant.b.edwards Yow! What PROGRAM are they
at watching?
gmail.com
Seebs
>> I agree with Seebs, Python is the only language I know that promotes the
>> use of spaces over tabs;
> Really?
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.
>> 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*.
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
Seebs
> On 2010-11-03, Seebs <usenet...@seebs.net> wrote:
>> Explicit is better than implicit. It is *better* to explicitly mark the
>> ends of things than to have it be implicit in dropping indentation. That's
>> not a burden, it's good engineering practice.
> Dededenting does explicitly mark the end of a block.
If you can't point to the token, it's implicit. :)
Tim Harig
>>> 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?
>
> Yes, and I also said that I sympathized with him if he couldn't.
Perhaps it would be more constructive, for everybody, to make suggestions
on how to reliably transfer code using channels that distort whitespace.
>>> 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.
>
> 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?
Please to not mix my contentions with somebody else's. I have not,
anywhere in this thread, asked to change the language. I certainly
didn't say *anything* about adding "BEGIN END" tags to the code itself.
I did say that I found code folding markers in the comments to be a
useful form for expressing code structure; but, that has nothing to with
chainging Python itself. I also expressed my opinion that I felt spaces
for indenting was a poor choice for the standard; but, since it is also
not part of the language proper, it can safely be ignored.
What I did suggest was a more constructive way of dealing with these
criticisms. You said that you found it "*incredibly* annoying" to have
this to see the same old "snide remarks" from "the same old people." I
merely suggested that if the community changes its attitude towards those
making those remarks, that it might go a long way towards silencing some of
those descents. The fact that you are unwilling to make these changes
makes me question your conviction when you claim to be so annoyed.
>> 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.
I understand that you don't like braces; but, I have nowhere advocated
adding them to the Python langauge. That is a different argument that you
are having with Seebs.
> Frankly, I DON'T CARE how often your editor breaks your source code. I
Only you have even mentioned editors in this thread.
> 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
Nobody else mentioned ftp servers in this either; but, I must admit that
you are doing a good job of providing evidence for the alternate viewpoint.
> 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.
Then why bother adding to the noise in this thread at all since it has
nothing to do with you? I see however, since you have brought all this
baggage to the table that was not otherwise in the thread, that you
obviously have a axe to grind.
> 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?
Then please state your Python language issues rather simply grinding your axe
against those who are stating theirs.
Steven D'Aprano
>>> 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.
>
> I don't think I buy this. I've seen a whole lot of good writers and
> good programmers, and in both groups, they consistently report that you
> have to know how the rules work before you break them.
Yes. How does that contradict what I said?
There is a huge difference between knowing when to break the rules, and
avoiding the rules because there might someday be an exception.
>> 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.
>
> I don't think there's a particularly big burden there.
Good for you.
> Explicit is better than implicit.
Ah, argument by misunderstanding the Zen!
> It is *better* to explicitly mark the
> ends of things than to have it be implicit in dropping indentation.
> That's not a burden, it's good engineering practice.
Python does explicitly mark blocks. It does it by changes in indentation.
An indent is an explicit start-block. An outdent is an explicit end-
block. There is nothing implicit in a change in indent level.
To illustrate the difference, this is how a hypothetical language might
use implicit end of blocks:
if condition:
true_clause()
another_true_clause()
else:
false_clause()
The if block ends implicitly when you reach an else statement, and the
else clause implicitly ends... where?
It gets worse:
if condition:
if another_condition:
true_clause()
else:
false_clause()
another_clause()
Such a hypothetical language might decide on a rule that else will always
match the closest if, or the outermost if that is legal. That would be an
implicit end of block. This is not even within the same galaxy as what
Python does.
It simply isn't possible to have implicit start/end block markers, unless
you restrict your language in ways that exclude most blocks. E.g. if all
if blocks were restricted to a single statement, then you could have an
implicit block -- the block in one statement. Stating that Python uses
implicit block markers is simply wrong.
--
Steven
Steven D'Aprano
> I'm not expecting it to change;
Then why talk about it? Just to hear the sound of your voice? (Or see the
font of your writing?) To waste our time? To feel more virtuous than
those who don't see your point of view?
If you don't expect a change, what's the point of this discussion?
> I'm pointing out that insisting that it's not a problem is
> *insulting* to the people for whom it is a problem.
And insisting that it is a problem is equally insulting to those for whom
it is not a problem.
--
Steven
Rhodri James
> On 2010-11-03, Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au>
> wrote:
>> On Tue, 02 Nov 2010 19:26:56 +0000, Tim Harig wrote:
>>
>>> 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).
>
> 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.
I regard this as a strength. I have wasted far too much time at work
writing review comments that could be paraphrased as "your broken editor
settings have made this (C code) unreadable."
--
Rhodri James *-* Wildebeest Herder to the Masses
Tim Chase
>> Dededenting does explicitly mark the end of a block.
>
> If you can't point to the token, it's implicit. :)
Just because you asked for it to be pointed to:
http://svn.python.org/view/python/trunk/Include/token.h?view=markup
The DEDENT token is explicitly defined as the number "6", FWIW...
:)
-tkc
Seebs
> On Wed, 03 Nov 2010 20:30:43 +0000, Seebs wrote:
>> I'm not expecting it to change;
> Then why talk about it?
Because I find technical questions interesting in and of themselves. I
will happily talk with people about the reasons for which the C preprocessor
is the way it is, even though it's never going to change and we all
hate it like poison.
>> I'm pointing out that insisting that it's not a problem is
>> *insulting* to the people for whom it is a problem.
> And insisting that it is a problem is equally insulting to those for whom
> it is not a problem.
No, it isn't.
A friend of mine is colorblind. For him, certain red/green pairings are
indistinguishable. For me to insist that it is not a problem that a
user interface uses those to distinguish two things is insulting to
him; I am dismissing a very real problem. For him to insist that it
is a problem for him is in no way insulting me. He's not saying that it's
a problem for me. He's merely saying that *there exist* people for whom
it is a problem.
No one has claimed that this is a problem *for everybody*. Just that
there exist real-world workflows for which it is a problem, or people
for whom it is a problem.
This is an asymmetrical situation. The opposite of "it's never a
problem for anybody" isn't "it is always a problem for everybody"
but "it is at least sometimes a problem for at least some people."
The reality is, the indentation-instead-of-markers thing *does* sometimes
lead to problems. We could blame it on tools, but the tools could just as
easily blame the language for being brittle. Given the degree to which
the rest of the world has standardized on not caring how *much*
whitespace is between things (though sometimes caring whether or not
there's *any* whitespace between them), it seems to me that the odd
man out is the one who is creating the burden.
Once many file formats exist which don't care how many spaces you
use, and many tools have been developed with those file formats in
mind, coming up with a new file format which cares how many spaces you
use seems a little short-sighted. Demanding that all tools be changed
to fit a new paradigm is a pretty big demand to place on people.
On the whole, I don't personally think the benefits have been worth it.
I think Python would be a better, richer, language if it used explicit
end tokens of some sort. Maybe it wouldn't. I do know, though, that
of the programmers I know outside the Python newsgroup, not a single
one likes that aspect of Python. It is consistently regarded as an
annoying quirk. Some use Python anyway; it has merits, certainly. If
I were offered a choice between Python and PHP for a project, I would
*absolutely* pick Python. (Subject, of course, to the assumption that
the project would in some way involve computers, or programming, or
that I would at some point have to either write code for the project
use it, or possibly come within twenty feet of someone who was working
on it; outside of those limitations, I might consider PHP.)
I feel the same way about pretty much every language I use. C would
be a much better language if the macro processor weren't such a giant
filesystem verification stage for a filesystem distributed across
multiple machines*. They all have flaws.
Python's the only language I use where an obvious flaw, which is repeatedly
observed by everyone I know who uses the language, is militantly and
stridently defended by dismissing, insulting, and attacking the character
and motives of anyone who suggests that it might be a bit of a nuisance.
I suspect part of that is simply because it *is* a tradeoff, and there
are good reasons for it. It offers some advantages. It's not something
that you'd be insane to like; the problems are easily mitigated once you
know about them, and the benefits are worth it. If I worked with a lot
more novice-level C programmers who hadn't yet had the importance of
careful style drilled into them, I might well find the indentation problems
people keep talking about to be a real thing, possibly even a very
serious one.
But the fact remains, being brittle in the face of whitespace changes *is*
a flaw. It breaks code under circumstances which are, for better or
worse, common. As I pointed out before: There is a *REASON* that diff
has an option for ignoring whitespace changes -- because they are common
enough that such an option is commonly useful for distinguishing between
real changes and inadvertant ones.
Note that "whitespace indentation" in and of itself isn't the thing I'm
describing as a flaw; it's the side-effect of being brittle when whitespace
changes. The indentation thing as a whole has some definite plusses, and
it's a tradeoff that I think may even be a good fit for a language
specifically focused on easier readability.
-s
[*] clusterfsck.
Michael Torrie
> Furthermore, I don't WANT to skip closing braces. EXPLICIT IS BETTER
> THAN IMPLICIT. I *WANT* to have the beginnings and ends marked.
I suggest, then that Pascal or Ruby would suit your needs better than
Python.
> I want end braces or "end" or something at the end of a block for
> the same reason that I prefer:
> x = "hello, world"
> to
> x = "hello, world
> where we just assume the string ends at the end of the line.
Not even close to the same thing, sorry.
As for refactoring code, vim makes it really easy to move blocks in and
out. The only time I could see this becoming an issue is if functions
or blocks of code are too long to see on a page at once. If this is the
case, break them up. Sounds to me like your problems with refactoring
and indention in python could be do to these kinds of design issues.
Having curly braces certainly doesn't help in these situations either.
More than once I've had C code I was refactoring that broke due to the
fact that while trying to move blocks around I misplaced a brace, an
issue I never have in Python.
In the meantime, whitespace structure is one of the things about Python
that I like the *most* about the language. Being able to crank out
executable pseudo-code is pretty addictive. And I never write
pseudo-code on paper with begin and end blocks cause it's too much
effort when scribbling by hand.
Ben Finney
> On 2010-11-03, Steven D'Aprano <steve-RE...@cybersource.com.au> wrote:
> > Python does explicitly mark blocks. It does it by changes in
> > indentation. An indent is an explicit start-block. An outdent is an
> > explicit end- block. There is nothing implicit in a change in indent
> > level.
>
> What's the token that marks the end of a block, corresponding to the
> colon used to introduce it?
You have introduced this requirement for tokens; it's fallacious. The
direct answer is: tokens aren't part of the requirement to be explicit.
The more general answer is: the block is explicitly ended where the
indentation ends.
--
\ “I must say that I find television very educational. The minute |
`\ somebody turns it on, I go to the library and read a book.” |
_o__) —Groucho Marx |
Ben Finney
Ben Finney
> Furthermore, I don't WANT to skip closing braces. EXPLICIT IS BETTER
> THAN IMPLICIT. I *WANT* to have the beginnings and ends marked.
Python doesn't require that. You're going to be disappointed by most
Python code if that's what you want.
Which is not a failing of Python.
--
\ “Few things are harder to put up with than the annoyance of a |
`\ good example.” —Mark Twain, _Pudd'n'head Wilson_ |
_o__) |
Ben Finney
Seebs
> I suggest, then that Pascal or Ruby would suit your needs better than
> Python.
In the absence of network effects, I'd just be using Ruby. I have reason
to work with projects that have a lot of existing Python, though, so I
use it too.
> As for refactoring code, vim makes it really easy to move blocks in and
> out.
Yes, though I mostly use nvi, same thing -- basically. The issue I've
had is that the automatic-tab thing (which I actively want for everything
else I edit) tends to make it quirky.
> The only time I could see this becoming an issue is if functions
> or blocks of code are too long to see on a page at once. If this is the
> case, break them up. Sounds to me like your problems with refactoring
> and indention in python could be do to these kinds of design issues.
> Having curly braces certainly doesn't help in these situations either.
> More than once I've had C code I was refactoring that broke due to the
> fact that while trying to move blocks around I misplaced a brace, an
> issue I never have in Python.
For me, I'd rather have the compiler choke because I have mismatched
braces than have the code run apparently just fine except that something
has unintentionally moved in or out of an else clause because there was
no marker. I've had both happen, probably.
> In the meantime, whitespace structure is one of the things about Python
> that I like the *most* about the language. Being able to crank out
> executable pseudo-code is pretty addictive. And I never write
> pseudo-code on paper with begin and end blocks cause it's too much
> effort when scribbling by hand.
I never write on paper anyway. :)
Anyway, I'm not disputing that there are things that it makes nicer. I'm
just observing that there exists a category of failures which is completely
unique to Python, which no other language (except BF, which I'm not sure
I ought to count) has, which tends to show up occasionally until you've
gotten all the changed tools and habits, and even then can show up when
dealing with other people who use tools which, well, work perfectly for
everything else. But not for this.
Only other tool I know with a comparable dependance on spacing is Makefiles,
and I have never in my life met someone who used them and didn't think
that was a loathesome error which should never have made it into
production code. Python's not nearly as bad, actually. :)
Lawrence D'Oliveiro
> 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.
Except the diff option is to *ignore* such differences, not highlight them.
Lawrence D'Oliveiro
> It is extremely useful to me to have spaces converted to tabs
> for every other file I edit.
I’m thinking of going the other way. After many years of treating tabs as
four-column steps, I might give up on them and use spaces everywhere.
Emile van Sebille
> What's the token that marks the end of a block, corresponding to the
> colon used to introduce it?
>
My thoughts tend more towards 'can we get Guido to eliminate the colon
requirements' -- The indent level of the next line ought to suffice.
Seriously.
Emile
Seebs
> In message <slrnid0ked.t7k...@guild.seebs.net>, Seebs wrote:
>> It is extremely useful to me to have spaces converted to tabs
>> for every other file I edit.
> I???m thinking of going the other way. After many years of treating tabs as
> four-column steps, I might give up on them and use spaces everywhere.
I *absolutely must* use tabs for Makefiles.
For code in most other languages, it's merely a factor of 8 improvement
in storage. :)
Seebs
Yes. That's because those changes are irrelevant, so people don't
care about them, so they want an option to handle the common case where
whitespace got changed but no one cares about that.
But unintentional whitespace changes are common enough that you *need*
the ability to filter them out and just look at "real" changes.
Grant Edwards
But without the colon, how are people who write programming editors
going to know when to increase the indentation level as I enter code?
> Seriously.
Just as seriously.
Syntactic sugar isn't just for humans...
--
Grant
Grant Edwards
> On 2010-11-04, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:
>> In message <slrnid0ked.t7k...@guild.seebs.net>, Seebs wrote:
>>> It is extremely useful to me to have spaces converted to tabs
>>> for every other file I edit.
>
>> I???m thinking of going the other way. After many years of treating tabs as
>> four-column steps, I might give up on them and use spaces everywhere.
I quit using tabs (except for Makefiles) about 30 years ago.
> I *absolutely must* use tabs for Makefiles.
And my editor (emacs) knows that. It uses tabs in Makefiles and
spaces everywhere else.
> For code in most other languages, it's merely a factor of 8 improvement
> in storage. :)
That's only true if your source code consists entirely of tabs.
;)
--
Grant
Steven D'Aprano
> On 2010-11-03, Steven D'Aprano <steve-RE...@cybersource.com.au>
> wrote:
>> Yes. How does that contradict what I said?
>
> Once you understand that you do have to break the rules occasionally, it
> is a good idea to design things that will be robust when the rules are
> broken.
That does not follow.
As a general rule, one should not expect that electronic equipment should
be safe to operate under water. But there are exceptional cases. So what
should we do?
(1) Insist that all consumer electronic equipment is designed to operate
under water? (All blocks need redundant START/END tags just in case
you're operating in an environment where indentation can't be trusted.)
(2) Tell people not to drop their toaster into the bath tub, and leave it
up to the exceptional cases to deal with the need for water-proof
electronics in whatever way they see fit? (Trust the indentation, tell
people not to mangle their source files with dodgy mail servers, and if
you need redundant tags, build your own solution.)
>> Ah, argument by misunderstanding the Zen!
>
> I see. So explicit boundaries are a good thing, except when they are
> one specific special case.
INDENT/OUTDENT is an explicit boundary.
> Let us imagine a hypothetical mirror-universe person, who is otherwise
> like you, but:
>
> 1. Has a goatee.
> 2. Actually hates the indentation rules, wishes Python had braces, but
> has become emotionally invested in defending the status quo because if
> he had to suffer, dammit, everyone else should have to suffer too.
I had to suffer?
Funny, I hardly noticed.
> You have not yet made a single argument that he wouldn't have made too.
The arguments Evil-Steven would make would be your arguments:
* redundant BEGIN/END tags make blocks robust in environments where
indentation can't be trusted;
* there are tools out there that assume that indentation is meaningless,
and some people want to use those tools, so the language is poorly
designed;
I *understand* your arguments, I just don't value them. But in fact, non-
evil Steven made the opposite arguments:
Re extra redundancy: you aren't going to need it often enough to make up
for the extra effort of dealing with BEGIN/END tags that can contradict
the indentation.
Re tools: if the tools don't fit your use-case, your tools are broken,
and you should change your tools.
>>> It is *better* to explicitly mark the ends of things than to have it
>>> be implicit in dropping indentation. That's not a burden, it's good
>>> engineering practice.
>
>> Python does explicitly mark blocks. It does it by changes in
>> indentation. An indent is an explicit start-block. An outdent is an
>> explicit end- block. There is nothing implicit in a change in indent
>> level.
>
> What's the token that marks the end of a block, corresponding to the
> colon used to introduce it?
Your assumption is incorrect. Blocks are introduced by an increase in
indentation level, not by a colon. The colon is enforced, but it's there
for the benefit of readability rather than to mark a new block. You can
write:
if condition: true_clause()
else: false_clause()
No blocks are started, the clauses are limited to a single line, but the
colons are still required.
To end the block, you need a decrease in indentation limit. In fact, the
Python parser actually places overt INDENT/OUTDENT tokens into the token
stream.
# From token.py:
INDENT = 5
DEDENT = 6
>> It simply isn't possible to have implicit start/end block markers,
>> unless you restrict your language in ways that exclude most blocks.
>> E.g. if all if blocks were restricted to a single statement, then you
>> could have an implicit block -- the block in one statement. Stating
>> that Python uses implicit block markers is simply wrong.
>
> No, it isn't. There's no token telling you where the block ended.
I disagree, but for the sake of the argument let's suppose you are
correct. So what?
x = 123+456
There's no tokens telling you where the ints 123 and 456 begin and end
either. So where's the problem?
Signals, or tokens if you like, can be explicitly made either by placing
a distinct marker (a delimiter or separator), or by a change of state. In
the case of ints, the explicit end-of-token is a change of state, not a
marker:
digit digit digit non-digit
There's no need for a distinct End Of Int marker, because the change of
state is explicit enough. But this is not the case for strings, which you
mentioned in an earlier post. Strings require a special BEGIN/END tag
because they may be terms in expressions and you can't assume they will
end at the end of the line (a change of state).
If you have an environment where strings do end at the end of the line,
such as INI files, you can avoid the delimiters:
[section]
x = Hello world.
y = Goodnight Gracie!
but in a general purpose programming language where strings can be terms
in expressions, you need delimiters.
Blocks are more like ints than strings. They don't need delimiters,
because they start and end according to an explicit change of state.
--
Steven
Steven D'Aprano
> No one has claimed that this is a problem *for everybody*. Just that
> there exist real-world workflows for which it is a problem, or people
> for whom it is a problem.
And people have suggested that if your workflow leads to indentation
being mangled and your source code no longer running, the solution is to
change the workflow. If you can't change the workflow, you have my
sympathy, but that's not Python's fault, and Python isn't designed for
your use-case of web servers that convert your source code to HTML and
text editors that mangle indentation.
Nor is Python designed for use on computers where the file system
randomly corrupts files, or a work-flow where your Pointy-Haired boss
keeps making random changes to production scripts in an effort to prove
he knows best. If you have such a work-flow, don't suggest that we should
add error-correcting codes to the language in order to fix your problem.
We can sympathize with your troubles while still saying Not Our Problem.
> Given the
> degree to which the rest of the world has standardized on not caring how
> *much* whitespace is between things (though sometimes caring whether or
> not there's *any* whitespace between them), it seems to me that the odd
> man out is the one who is creating the burden.
What burden? You keep talking about this burden of not-having-to-type-
braces, but I don't see any burden, and nor do the majority of Python
programmers.
What we see is dozens of languages, and thousands of people, who have
built all these wonderful devices and tools for helping them carry a
refrigerator on their head (a bar fridge, naturally, it would be foolish
to carry a full-sized fridge and freezer combo). That's fine if you need
to carry a fridge on your head, and I'm really glad that your tools take
90% of the weight for you. I'm sure you hardly even notice it any more.
But then you start arguing that it's *really important* to carry a fridge
on your head *everywhere* because you never know when you'll be somewhere
where you MUST HAVE a fridge, and all hell will break loose if you don't
have one, well, we just think you're a bit strange.
It's not that we don't think fridges are useful. And we understand the
logic -- yes, if you need a fridge and don't have one, bad things will
happen, but why limit it to fridges? Why not a sewing machine, and a jack
hammer, and a piano, and ... there's no limit to the number of things you
might need, and the difference in risk between not having any of them and
not having any of them bar one is negligible.
And then you start telling us how we're the weird ones because we have
the "burden" of not-carrying-a-fridge everywhere!
--
Steven
Seebs
> And people have suggested that if your workflow leads to indentation
> being mangled and your source code no longer running, the solution is to
> change the workflow.
Yup.
But it strikes me as unmistakably a shortcoming of Python (and Makefiles,
for that matter) that code for them can't survive a common failure mode
that everything else I use can.
> What burden?
The burden of using different tools because suddenly the version of vi
I've been using since 1990 is magically "broken" even though it's never
caused a problem before.
> You keep talking about this burden of not-having-to-type-
> braces, but I don't see any burden, and nor do the majority of Python
> programmers.
Of course not. Most of the people who find it annoying *don't use Python*.
Of the programmers I know who don't use Python, 100% have cited the annoyance
value *to them* of the whitespace thing as the main reason they don't. Of
the programmers I know outside this newsgroup who *do* use Python, 100% have
said the whitespace thing is annoying and they wish Python didn't have it,
but they have to use Python for some externally-imposed reason, so they put
up with it.
Outside of people who seem to be deeply emotionally invested in insisting
that it is never, at all, in ANY way, for ANY person, annoying, it seems
to be pretty consistent to observe that, benefits or no benefits, it has
some kind of non-zero annoyance value.
Other languages I use are mostly amenable to the development of tools
to automatically indent code. Makefiles and Python are the only two
exceptions... And if I were an advocate for a language, the fact that it's
lumped itself in with Makefiles in a significant way would be a weakness
I'd feel obliged to be up front about. :)
The underlying issue is this:
* Not having to type braces: Yay!
* Having structure map to functionality: Some people quite like it, and
certainly there exists a class of theoretical errors which it prevents.
* Not being able to write an auto-indenter, ever, because it is by
design theoretically impossible: Annoying.
I guess if people could show me some of these errors in other languages
where indentation is misleading and bugs resulted, I'd be more persuaded
by the second point there. As is, I find the brittleness more annoying
than I've ever found braces or 'end' or whatever. It's not annoying
enough for me to refuse to use the language when there are other
compelling reasons to, but it's certainly annoying enough that I'll never
use Python for something where I have unfettered choice of language. It's
less fun to program in, for me.
-s
Antoon Pardon
> On Wed, 03 Nov 2010 12:01:06 +1300, Lawrence D'Oliveiro wrote:
>
> > In message <ianem3$cuq$1...@reader1.panix.com>, Grant Edwards wrote:
>
> >> 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???.
>
> (1) Indentation is visible. Compare:
>
>
> This line has leading visible whitespace.
>
> This line has leading invisible characters.
>
> See the difference?
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.
Indentation may be visible, but it is not context-free visible, It only
becomes visible by looking by introducing context. So because it is only
visible by looking at the context I would say the end of a block i made
implicitly and not explicitly
--
Antoon Pardon
Grant Edwards
>> And people have suggested that if your workflow leads to indentation
>> being mangled and your source code no longer running, the solution is to
>> change the workflow.
>
> Yup.
>
> But it strikes me as unmistakably a shortcoming of Python (and Makefiles,
> for that matter) that code for them can't survive a common failure mode
> that everything else I use can.
I think the issue is that for whatever reason, white-space mangling is
"a common failure mode" for you. I don't ever remember it happening
to me. If whitespace mangling is common for you, then you just
shouldn't be using Python any more than somebody who works on a system
that randomly changes/deletes the strings "begin" and "end" should be
using Pascal.
--
Grant Edwards grant.b.edwards Yow! PEGGY FLEMMING is
at stealing BASKET BALLS to
gmail.com feed the babies in VERMONT.
Ethan Furman
> On 2010-11-04, Emile van Sebille <em...@fenx.com> wrote:
>> On 11/3/2010 4:09 PM Seebs said...
>>
>>> What's the token that marks the end of a block, corresponding to the
>>> colon used to introduce it?
>>>
>>
>> My thoughts tend more towards 'can we get Guido to eliminate the colon
>> requirements' -- The indent level of the next line ought to suffice.
>
> But without the colon, how are people who write programming editors
> going to know when to increase the indentation level as I enter code?
>
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~
Antoon Pardon
> Antoon Pardon wrote:
> >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.
> 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.
That one piece of code is only three lines and the other is four
doesn't make them not equivallent. Adding a fourth (empty) line
to the python example wouldn't have changed things significantly.
These two pieces are equivallent in any significant way. Both
are examples of a for loop, one with its block the other with
its suite. They are both complete for-statements as defined by
the respective grammes. Both perform the same functionality.
The complete for-statement is all you need to see, to know
you are seeing the complete for-statement in the first example.
So all you need is in context information.
To know you see the complete for statement in python, you need
to see more than just the complete for-statement. You need out
of context information.
--
Antoon Pardon
Neil Cerutti
The handsome ':' terminator of if/elif/if statements allows us to
omit a newline, conserving vertical space. This improves the
readability of certain constructs.
if x: print(x)
elif y: print(y)
else: print()
versus
if x
print(x)
elif y
print(y)
else
print()
Beauty-is-in-the-eye-of-the-BDFLly-yours,
--
Neil Cerutti
D'Arcy J.M. Cain
Seebs <usenet...@seebs.net> wrote:
> Outside of people who seem to be deeply emotionally invested in insisting
> that it is never, at all, in ANY way, for ANY person, annoying, it seems
> to be pretty consistent to observe that, benefits or no benefits, it has
> some kind of non-zero annoyance value.
Who are these people that believe that no one finds indentation as
syntax annoying? I haven't seen any evidence in this group. Let's
leave the straw men out of this. Many of us don't find it annoying
ourselves, that's for sure but we aren't trying to read anyone else's
mind. We're all pretty sure that *you* find it annoying but there is
no telepathy involved there.
> * Not having to type braces: Yay!
Which I always found annoying given that I was already adding signals
(indentation) that I was starting a block.
> * Having structure map to functionality: Some people quite like it, and
Some of us think that it is a contender for the single greatest thing
about Python.
> * Not being able to write an auto-indenter, ever, because it is by
> design theoretically impossible: Annoying.
Right. And in C you can never write an auto-bracer for exactly the
same reason.
--
D'Arcy J.M. Cain <da...@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
John Nagle
> Le 31/10/2010 13:10, Martin v. Loewis a écrit :
>>> I've a project with tabs and spaces mixed (yes I know it's bad).
>>>
>>> I edit each file to remove tabs, but it's so easy to make a mistake.
>>> Do you know a tools to compare the initial file with the cleaned one to
>>> know if the algorithms are the same ?
>>
>> Tools/scripts/reindent.py of the standard Python distribution normalizes
>> white space in source code.
>
> So great, you save my time !
> Should I be worry about this comment in reindent.py "So long as the
> input files get a clean bill of health from tabnanny.py, reindent should
> do a good job." ?
Are both of those tools consistent with the interpretation of mixed
tabs and spaces in Python 3.x?
The current CPython parser front end is smart about this. Tabs
and spaces can be mixed provided that the semantics of the program
do not depend on the width of a tab. This was not the case in
early 2.x versions. (When did that go in?)
The key to doing this right is to compare the whitespace of an
indented line with the line above it. The longer whitespace string must
start with the shorter whitespace string, whether it's tabs, spaces, or
any combination thereof. If it does not, the indentation is ambiguous.
For all unambiguous cases, you can then convert tabs to spaces or vice
versa with any number of spaces to tabs, and the semantics of the
program will not change.
It's not clear whether "tabnanny" or "reindent" have smart semantics
like CPython. The documentation doesn't say. If they don't, they
should, or it should be documented that they're broken.
John Nagle
Mark Wooding
> Python's the only language I use where an obvious flaw, which is
> repeatedly observed by everyone I know who uses the language, is
> militantly and stridently defended by dismissing, insulting, and
> attacking the character and motives of anyone who suggests that it
> might be a bit of a nuisance.
So you've not tried Lisp, then? Dissing Lisp's parentheses tends to get
a pretty similar reaction.
My observations on this general discussion.
* Python is far from unique in its use of significant whitespace.
Miranda was inferring program structure from indentation in 1985.
Haskell and F# are more modern examples.
* I don't have many problems with tools trashing whitespace in Python
programs, though I have seen web forum software mangling
indentation; since this makes nontrivial chunks of almost any
programming language illegible, I'm more than willing to blame the
forum software for this. I haven't personally seen indentation
trashed by email software, for example (though I steer well clear of
people who try to send me HTML mail).
* 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.
* I've just noticed that Emacs's Python mode has a magic keystroke
which appears to do the right thing for cut-and-pasted code. This
is symptomatic of a bigger problem: simply by being different from
the mainstream, Python requires that one work with it differently.
It requires different tools, and different techniques. Many
languages use some kind of brackets to mark substructure, so tools
have become good at handling bracketed substructure, whether for
automatic indentation or navigation. Python marks (some)
substructure differently, so users need to learn new techniques or
tools for working with it.
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.
-- [mdw], a smug Lisp weenie at heart.
Mark Wooding
> 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.
You need to get out more. Miranda, Gofer, Haskell, F#, make(1), and
many others, all use indentation to indicate structure; YAML isn't a
programming language, but it also uses indentation to indicate
structure, as do a number of wiki markup languages; there are also
representations of Lisp S-expressions which use indentation instead of
parentheses.
> Mixed usage may be annoying in other languages; but, it breaks Python.
I disagree. The Haskell '98 report specifies (correctly) that tabs are
every eight columns, and a tab moves to the next tab stop. Python makes
the same specification; it's just the users who actually want to stamp
out tabs.
Flamebait: it's not the tabs that cause the problem: it's that some
people are under the mistaken impression that the position of tab stops
in text files is a matter for local preference.
-- [mdw]
Neil Cerutti
>> * Not being able to write an auto-indenter, ever, because it
>> is by design theoretically impossible: Annoying.
>
> Right. And in C you can never write an auto-bracer for exactly
> the same reason.
It's not right, actually. Auto-indent is fairly easy in
Python. Auto-dedent is the impossible part.
--
Neil Cerutti
Grant Edwards
I think in common usage the term "auto-intender" refers to a program
that can automatically control source indentation (which inclulde both
"indenting" and "dindenting" source lines).
--
Grant Edwards grant.b.edwards Yow! I'm having BEAUTIFUL
at THOUGHTS about the INSIPID
gmail.com WIVES of smug and wealthy
CORPORATE LAWYERS ...
MRAB
> Seebs<usenet...@seebs.net> writes:
>
>> Python's the only language I use where an obvious flaw, which is
>> repeatedly observed by everyone I know who uses the language, is
>> militantly and stridently defended by dismissing, insulting, and
>> attacking the character and motives of anyone who suggests that it
>> might be a bit of a nuisance.
>
> So you've not tried Lisp, then? Dissing Lisp's parentheses tends to get
> a pretty similar reaction.
>
> My observations on this general discussion.
>
> * Python is far from unique in its use of significant whitespace.
> Miranda was inferring program structure from indentation in 1985.
> Haskell and F# are more modern examples.
>
> * I don't have many problems with tools trashing whitespace in Python
> programs, though I have seen web forum software mangling
> indentation; since this makes nontrivial chunks of almost any
> programming language illegible, I'm more than willing to blame the
> forum software for this. I haven't personally seen indentation
> trashed by email software, for example (though I steer well clear of
> people who try to send me HTML mail).
>
If you don't use <pre> ... </pre> or some such then any programming
language is going to look bad!
[snip]
Emile van Sebille
> The handsome ':' terminator of if/elif/if statements allows us to
> omit a newline, conserving vertical space. This improves the
> readability of certain constructs.
>
> if x: print(x)
> elif y: print(y)
> else: print()
>
Analogously, x+=1;y=f(x);return
We don't have to eliminate ':'s.
Emile
Tim Harig
> Tim Harig <use...@ilthio.net> writes:
>
>> 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.
>
> You need to get out more. Miranda, Gofer, Haskell, F#, make(1), and
I have never heard of Gofer.
I have heard the name Miranda and I know that it is a (purely?) functional
language; but, that is all that I know.
I took a cursory look at Haskell a while back; but, I ultimately chose to
learn Erlang instead as its error management constructs had real world
application for me.
I also looked at F# and Scala; but, neither are really applicable on my
chosen platform. With F# being such a new language, I suspect that it
borrowed its indent practices either from Haskell or from Python.
I already introduced the make tab oriented syntax and Seebs has labeled it
as a major anti-pattern.
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.
>> Mixed usage may be annoying in other languages; but, it breaks Python.
>
> I disagree. The Haskell '98 report specifies (correctly) that tabs are
> every eight columns, and a tab moves to the next tab stop. Python makes
> the same specification; it's just the users who actually want to stamp
> out tabs.
So, your telling me that mixing tabs and spaces is considered a good
practice in Haskell? No, mixing tabs and spaces in Python isn't illegal;
but, I have never seen good outcomes from doing so. No matter how you
define a tab, most people do not have their editor configured to show them
the difference between a tab stop and the equivilant number of spaces.
I have never experienced ill effects from using tabs alone.
> Flamebait: it's not the tabs that cause the problem: it's that some
> people are under the mistaken impression that the position of tab stops
> in text files is a matter for local preference.
I would argue that text files do not have tab stops -- text editors do. So
long as you use tabs for all of your indenting, it is quite safe to set the
editors tab stops however one likes since the editor's tab stop doesn't
effect the output of the file. That way, everybody can edit their code
using an apparent indent level that is comfortable for them without being
disruptive to the code. It is a win-win situation for everybody.
Tim Harig
>>> * Not being able to write an auto-indenter, ever, because it
>>> is by design theoretically impossible: Annoying.
>>
>> Right. And in C you can never write an auto-bracer for exactly
>> the same reason.
>
> It's not right, actually. Auto-indent is fairly easy in
> Python. Auto-dedent is the impossible part.
What Seebs is refering to is that it is difficult or impossible to
re-indent Python source automatically after the indent structure has been
broken (such as his email being converted to html on the server or a web
forum without the possibility of <pre> or [code] tags). When C becomes
so obfiscated, you can run it through indent to recover the structure of
the source to something that you are familiar with (I actually think macros
could cause problems; but, Seebs has already admitted weaknesses in the C
preprocessor.). The same is not always true for Python where information
about the code structure may be destroyed.