Compare source code

[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!

 

[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]

(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

 

[Grant Edwards]

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.

 

[Antoon Pardon]

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

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.

 

[Neil Cerutti]

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

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,

 

[D'Arcy J.M. Cain]

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.

 

[John Nagle]

Le 31/10/2010 13:10, Martin v. Loewis a écrit :

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]

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.

 

[Grant Edwards]

It's not right, actually. Auto-indent is fairly easy in
Python. Auto-dedent is the impossible part.

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

 

[MRAB]

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.

occam was doing it in 1983.

* 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]

On 11/4/2010 7:15 AM Neil Cerutti said...

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]

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.

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]

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

 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.

 

[Tim Harig]

If you don't use <pre> ... </pre> or some such then any programming
language is going to look bad!

Looking bad and being unrecoverable are two different things.

 

[Neil Cerutti]

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

Thanks for the correction. Autoindent doesn't mean that to me
(I'm a vi user), but I should have figured out what he meant from
the context.

 

[D'Arcy J.M. Cain]

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

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

 

[Mark Wooding]

So, your telling me that mixing tabs and spaces is considered a good
practice in Haskell?

It doesn't seem to be a matter which is discussed much. I think Haskell
programmers are used to worrying their brains with far more complicated
things like wobbly[1] types.

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.

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

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

[1] Proper technical term. I kid you not.

-- [mdw]