Python indentation deters newbies?

[Dennis Lee Bieber]

But, you have to remember that in those days, CPU time was an expensive
and scarce resource, and languages were designed to be easy for the
computer to process. The thought of making the machine do something
that a person could do themselves was absurd.

So we end up with a language that can't separate a loop from an
assignment until it get to parsing the loop end-point

do10i=3,14159
vs
do10i=3.14159

The compiler has to either assume the "do" is a loop, the "10"
is a label, the "i" is the index variable, ignore the "=", assume the
"3" is the beginning of the index start range, find a "." and assume the
loop is over floating data, find the EOL after the "14159", check the
NEXT line for continuation marker... and then realize: Whoops, this is
an assignment...

OR assume "do10i" is a variable, the "=" signifies an assignment,
the "3" begins the expression, then find a "," which is not valid in an
assignment, and go back to try as a do loop. I, somehow, suspect the
first variant is more likely as it is using the minimal parse
"do"->attempt do loop, vs the greedy parse of "do10i" as a variable.

FORTRAN does not have a syntax easy for a computer to parse. It
had a syntax that was easy for a number-cruncher scientist to write
complex expressions with.

--

 

[Dennis Lee Bieber]

<addendum>

In some versions, a "D" in column 1 indicated a debug line, which was
conditionally included depending on some external compile flag.

Aye... and my college machine allowed for S in column 1.

S ld,9 xyz
S sub,9 abc
S st,9 mno ;I forget the old Xerox Sigma instruction set

Yes... A FORTRAN compiler that allowed for INLINE ASSEMBLY

--

 

[Keith P. Boruff]

One of the most commmon reasons programmers cite for not trying Python
is that indentation determines the program flow -- they think its
weird. I think programmers who actually try Python adapt quickly and
do not find the indentation rules to be a problem.

Honestly, I'm still not too crazy about the indentation requirements of
the language myself, coming from a background of using all free form
languages.

This isn't too big a deal though since I use emacs and the Python mode
basically does the indentation for me.

In addition, if anyone here has dealt with makefiles, I'm sure they're
well aware of the requirement to indent (in this case 'tab') certain lines.

Things I like about the language that offset my displeasure of the
indentation rules are:

1. The mechanics of the language are easy to pick up. No funky '$', '@'
decorators to deal with. There are the * and ** decorators that you can
use in function parameter definitions but that's not a big deal.

2. The language is well documented. I had to learn Python on the fly and
the documentation was excellent in getting me up to speed.

3. Good basic/standard API. Not too big; not too small and again... well
documented.

4. Nice, tight modularity.

If I have any big problem with python, it's in the semantics of the
classes. It seems a bit... well... weird in some cases. Two of the
things I don't like about it is that there's no access specifiers for
the class components (public, private, protected) like C++ and Ruby, for
example.

Also, I'm not too thrilled about the 'new class style' that I read about
in books.. meaning that you should inherit your base class from
'object'. To me, it seems a bit of a hack.

All in all though, a good language. I was able to construct a script
generator for one of our test programs at work using Python to access a
DB and put out flat file representations of the DB data in less than 3
days without being a 'super Python pro'.

Keith Boruff

 

[Porky Pig Jr]

One of the most commmon reasons programmers cite for not trying Python
is that indentation determines the program flow -- they think its
weird. I think programmers who actually try Python adapt quickly and
do not find the indentation rules to be a problem.

Not only it's *not a problem*. I've found it quite useful since it
forces you to keep the proper indentation.

Granted, the very first time I read about this feature, I've thought:
what a funny thing -- but then I've realized that since I keep the
proper indentation anyway, Python simply eliminates 'parenthetical
clutter' (in addition of forcing you to keep the code nicely
alligned).

For instance, in C I write

if (condition) {
statement-1
statement-2
}
else {
statement-3
statement-4
}

or some other coders prefer to write

if (condition) {
statement-1
statement-2
} else {
statement-3
statement-4
}

but in Python all those extra parenths are gone, and code is more
compact, more easily observable. you can squeeze more code into a
single displayble area which *is* important.

On the other hand, C has nothing that prevents someone from writing
the code:

if (condition) {
statement-1
statement-2 }
else {
statement-3
statement-4
}

Just had the situation a few weeks ago when novice C++ programmer
asked for help. Even if that programmer used emacs, somehow she has
managed to write the code as above. I simply told her to get her
identation in place first and then get back to me.

So: if you are a programmer who - as a matter of habit - writes nice
properly indented code, you will quickly appreciate the advantages of
Python (just like I did), and if you don't -- well, that's too bad.

 

[Y2KYZFR1]

One of the most commmon reasons programmers cite for not trying Python
is that indentation determines the program flow -- they think its
weird. I think programmers who actually try Python adapt quickly and
do not find the indentation rules to be a problem.

I wonder if there is a way to remove this initial barrier. Could an
alternate source form be defined, so that there are matching if-endif
and for-next constructs instead of significant indentation? The
alternate source form and the current form would result in exactly the
same .pyc file.

I'm not saying that Python's use of indentation is bad, just that it
stops many programmers from trying it.

then it is there loss that they are so stupid and closed minded to not
try something a better way

but don't go and make something crappy because of crappy people

 

[George Kinney]

I'm not saying that Python's use of indentation is bad, just that it
stops many programmers from trying it.

I thought it was a bit odd years ago when I first saw it, but then I spent
years writing code in ILE RPG. Which is a language where
actual line position of opcodes/values, etc matters. Which is quite a bit
more extreme than python's indented blocks. (Of course python
has now been ported to OS/400, or i5/OS as its called this month, so I can
use either. )

IBM did decide to produce a free-format version of RPG, which tosses the
learned readability of veterans in the trash in the hopes of attracting some
of these 'required-format-is-scary' programmers to the fold. Like this, and
not the fact that the OS/400 platform is fairly obscure to most programmers,
is the root cause of RPG programmers being hard to find.

Personally, if the first comment out of a new hire's mouth was a gripe about
how to format source code, I show them the door. If, a few months later,
they gripe about the format because it causes a real, measurable problem,
then I'll buy them a beer.

 

[Dennis Lee Bieber]

or some other coders prefer to write

if (condition) {
statement-1
statement-2
} else {
statement-3
statement-4
}

Missed one variant <G>... Since the brackets are, in my mind,
noise, I prefer to keep /them/ aligned (easiest means of drawing lines
on a listing...

if (condition)
{
stmt-1
stmt-2
}
else
{
stmt-3
stmt-4
}


--

 

[Peter Hansen]

I'm a Perl programmer at heart - well that and PHP, plus the odd
dabbling in C/C++/C# etc.

Anyway, the thought of indentation instead of curly braces really put
me off to start with,

Ah, good. Someone who was really there, instead of hearsay.

Please, *why* did it put you off?

Didn't you already indent your code consistently?

Didn't you think that the removal of those braces would immediately
make the code more readable (fewer lines, fewer extra cruft to
distract the eye) and easier to type?

I'm curious why more people don't have "neat!" as their very
first thought on encountering this, rather than "yuck!".

-Peter

 

[Peter Hansen]

Honestly, I'm still not too crazy about the indentation requirements of
the language myself, coming from a background of using all free form
languages.

Did you really not indent your code in those languages consisntly
anyway?

-Peter

 

[Peter Hansen]

Missed one variant <G>... Since the brackets are, in my mind,
noise, I prefer to keep /them/ aligned (easiest means of drawing lines
on a listing...

if (condition)
{
stmt-1
stmt-2
}
else
{
stmt-3
stmt-4
}

Missed another! (The best! ;-)

if (condition)
{
stmt-1;
stmt-2;
}
else
{
stmt-3;
stmt-4;
}

After all, the braces are basically part of the blocks, so they
really should be indented the same as the statements in the
blocks. Furthermore this way it's easier to scan down to find
the else or subsequent code. Basically, this way the braces
don't really get in the way at all, except for using up some
vertical space.

-indentation-wars-backwards-r-us-ly y'rs,
Peter

 

[Sam Holden]

Ah, good. Someone who was really there, instead of hearsay.

Please, *why* did it put you off?

Didn't you already indent your code consistently?

Didn't you think that the removal of those braces would immediately
make the code more readable (fewer lines, fewer extra cruft to
distract the eye) and easier to type?

I'm curious why more people don't have "neat!" as their very
first thought on encountering this, rather than "yuck!".

Many moons ago when I first programmed in python I disliked the
use of indentation instead of curly braces.

Solely because I was (and still am) from the tab school of indentation
but when copy-n-pasting sample code from an x-term or a web browser
spaces would get inserted and the code wouldn't be valid.

When writing code this isn't a real problem (since not much copy-n-paste
happens), but when playing around with things and trying stuff out it
makes things more painful than they need to be.

Of course that's a problem with the tools and not with the language - a
better editor would fix that as would "smarter" copy-n-paste.

But it was annoying.

The same thing crops up with Makefiles, but is even more annoying in
that domain.

 

[Grant Edwards]

Please, *why* did it put you off?

Dunno, it just did.

It seems to me that you're asking for a rational explanation
for an emotional response. It's like asking somebody "*why*
don't you like pickled beets?" The answer you get is "I just
don't." Perhaps they're just too different from what you're
used to eating. Perhaps there's something bad in your past
associated with beets. It doesn't really matter, since it's
not a reasoned, rational reaction.

Didn't you already indent your code consistently?
Sure.

Didn't you think that the removal of those braces would
immediately make the code more readable (fewer lines, fewer
extra cruft to distract the eye) and easier to type?
Sure.

I'm curious why more people don't have "neat!" as their very
first thought on encountering this, rather than "yuck!".

It's a good question, but based on my extensive background of 3
undergrad psych classes, I don't think you're going to get
accurate answers from the people experiencing the reactions.

I think my negative reaction was because my only previous
encounters with intentation significance was with Fortan IV and
with Makefiles. I find dealing with both of those unpleasant
(though I've gotten used to Makefiles over a period of 20+
years, I still trip of the "tab" thing several times a month --
at least Gnu make is kind enough to tell you exactly what you
did wrong).

In my case, I desperately needed a way to fetch e-mails from
MS-Outlook, and writing a Python program looked like my only
shot. So I went ahead and tried it. Within a few hours, I
discovered I liked Python way of indentation. Now, with the
exception of the occasional shell script, I use Python for
everything that's not embedded or in kernel space.

 

[Andrew Durdin]

I'm curious why more people don't have "neat!" as their very
first thought on encountering this, rather than "yuck!".

When I first encountered python, my response was "yuck" also, though
replaced in a few days with "neat". Having programmed quite a bit in C
(with explicit begin and end markers), as well as Basic (with explicit
end markers only), I think the initial reaction was mostly due to lack
of acclimatisation to having no explicit block end-markers.

 

[Peter Hansen]

Dunno, it just did.

It seems to me that you're asking for a rational explanation
for an emotional response. It's like asking somebody "*why*
don't you like pickled beets?" The answer you get is "I just
don't."

Hmm... not for me. The answer would be "because they
taste like dirt", or "I hate purple", or "anything pickled
sucks". "I just don't" looks a lot like a cop-out. If
it is an emotional reaction, then the reason someone doesn't
like pickled beets would be "because I have a negative
emotional reaction to them which I don't understand
and cannot put into words"... (but then writing about it
wouldn't make any sense ;-)

> Perhaps they're just too different from what you're
used to eating. Perhaps there's something bad in your past
associated with beets. It doesn't really matter, since it's
not a reasoned, rational reaction.

At the time you have the reaction, you may not understand
it. Afterwards, you should be able to analyze it and
explain it, I believe. But, whatever, we're different
people. I can generally explain my reactions to things
while perhaps you can't.

I think my negative reaction was because my only previous
encounters with intentation significance was with Fortan IV and
with Makefiles. I find dealing with both of those unpleasant

Ah, thank you! You _can_ do it. ;-) I'll buy this (not
that anyone should care whether I buy it or not ;-) as a
valid and interesting reason for an initially negative reaction
to Python's indentation.

The reason I'm asking this is because I believe that if there
really are a significant number of people with such a
reaction (not necessarily for the same reason as yours), then
if we can analyze and discover the most common reasons for
such a reaction, then it might well be possible to eliminate
the cause and avoid the reaction.

For example, if 90% of people who have the "indentation rash"
had previous encounters with FORTRAN IV, then it ought to
be possible to make it obvious in the early documentation
(tutorial, intro page, etc) that Python is not FORTRAN and
doesn't suffer from the same limitations with respect to
indentation/whitespace significance as FORTRAN does.

(Not that I think we'll really find this particular one
to be the biggie. But that roughly describes my purpose...)

-Peter

 

[Andrea Griffini]

For example, if 90% of people who have the "indentation rash"
had previous encounters with FORTRAN IV, then it ought to
be possible to make it obvious in the early documentation
(tutorial, intro page, etc) that Python is not FORTRAN and
doesn't suffer from the same limitations with respect to
indentation/whitespace significance as FORTRAN does.

(Not that I think we'll really find this particular one
to be the biggie. But that roughly describes my purpose...)

Not sure if this would help. I have to admit that at first
the idea of whitespaces instead of braces generated a general
repulsion. This probably due to FORTRAN or COBOL memories (note
that I never did any real work with those languages... just
high-school code snippets)... but the point is that this was
just BEFORE reading any documentation on python.
Before installing it and giving it a try the only source of
knowledge was an earsay that whitespaces was important in
python... and even if my memories of high-school are mostly
really nices this triggered an immediate "oh-no!".

There is no need to tell that now I'm just more than happy
to use indentation... it really works beautifully and takes
probably 5 minutes to forget braces for structure and see
how they are indeed noise and not information.

The only truly annoying thing is the hideous tab problem...
I've personally banned tabs since when they become unreliable
(i.e. when they lost their comfortable 8-spaces size: seems
that someone didn't understand that making a tab meaning
anything was indeed making tab mean nothing), but I'm
still fighting with collegues that on VC++ insist on
doing stupid things with tabs (like changing their size
every couple of months and keeping the "use tabs" checkbox
in the preferences dialog ... IMO basically because they
can't see the logical distinction between tab size and
indent size).

Andrea

 

[Antoon Pardon]

Did you really not indent your code in those languages consisntly
anyway?

I can't answer for keith, but my answer is that it depends on
what you consider consistent.

My indentation was consistent with the structure of the algorithm.
That is not necesarrily the same as the structure you implemeted
that algorithm in.

I think that I should be the final judge of what is the most
appropiate way to use indentation, not the compilor/interpreter,
even if it agrees with me.

 

[beliavsky]

For example, if 90% of people who have the "indentation rash"
had previous encounters with FORTRAN IV, then it ought to
be possible to make it obvious in the early documentation
(tutorial, intro page, etc) that Python is not FORTRAN and
doesn't suffer from the same limitations with respect to
indentation/whitespace significance as FORTRAN does.

Uh oh, people are picking on my beloved Fortran .

Fortran IV was standardized as Fortran 66. Even the following Fortran
standard, Fortran 77, had only "fixed format" with the rigid column
restrictions. The Fortran 90 standard introduced free format, and I
think such code resembles Python more closely than other compiled
languages, because there are no semicolons needed to terminate lines,
and curly braces are not used to delimit blocks.

It would be misleading to discuss certain flaws of earlier versions of
Fortran without mentioning that they have long since been corrected.
Btw, the official spelling has been "Fortran" (not all uppercase)
since the 1990 standard.

I have done a good bit of coding in both Python and Fortran and still
(mildly)prefer using key words rather than indentation to terminate
blocks, for example

do i=0,9
! some code
enddo

compared to

for i in range(10):
# some code

In Fortran you easily wrap a do-enddo or if-endif around a block of
code without touching the interior lines. This is useful for
debugging. If the change is permanent, the code should be re-indented.
In Python the indentation must be correct at all times, which can be
inconvenient.

 

[Peter Hansen]

I can't answer for keith, but my answer is that it depends on
what you consider consistent.

My indentation was consistent with the structure of the algorithm.
That is not necesarrily the same as the structure you implemeted
that algorithm in.

Huh? How does an algorithm have structure that affects
indentation? It sounds like you are talking about some kind
of artistic considerations here.

I think that I should be the final judge of what is the most
appropiate way to use indentation, not the compilor/interpreter,
even if it agrees with me.

So did you indent your code such that consecutive lines were
not indented to the same identation level even when they were
conceptually, logically, *algorithmically* part of the same
block?

I know there are such people out there. I even had to fire one
once, roughly because he had no concept of how his failure to
write his code with anything resembling consistent indentation
meant that it was unreadable to others. (At least, that was the
surface symptom which warned us of deeper problems.) What I
doubt is that many of those people are out there rejecting
Python just because it doesn't let them write god-awful unreadable
code with artistic or random indentation.

-Peter

 

[Antoon Pardon]

Huh? How does an algorithm have structure that affects
indentation? It sounds like you are talking about some kind
of artistic considerations here.

Simple: not all languages provide the same control structures.
So you have to use the control structures that are available
to simulate the control structure you really want to use.

So did you indent your code such that consecutive lines were
not indented to the same identation level even when they were
conceptually, logically, *algorithmically* part of the same
block?

No, but although they were *algorithmically* not in the same
block, due to lack of control-structures they had to be
implemented as being in the same block. In a language as
python, this would force IMO the indentation to be wrong.

I know there are such people out there. I even had to fire one
once, roughly because he had no concept of how his failure to
write his code with anything resembling consistent indentation
meant that it was unreadable to others. (At least, that was the
surface symptom which warned us of deeper problems.) What I
doubt is that many of those people are out there rejecting
Python just because it doesn't let them write god-awful unreadable
code with artistic or random indentation.

I don't reject python. There is still no language I find perfect.
I find python usefull and use it regularly, despite the details
I don't like about it. I don't like the enforced indentation,
even if I agree 99.99% of the time with the indentation python
enforces.

 

[Christopher T King]

What I doubt is that many of those people are out there rejecting Python
just because it doesn't let them write god-awful unreadable code with
artistic or random indentation.

Imagining ee cummings coding Python:

import
sys

def main ( )
:
myfile
= open

( s y s . a r g v [ 1 ] )

myfile
..
write('
hello

world ')myfile.



c
l
o
s
e


()main()