Python indentation

[Sateesh]

Hi,
I am a beginner in Python, and am wondering what is it about the indentation
in Python, without which python scripts do not work properly.
Why can't the indentation not so strict so as to give better freedom to the
user?
Is there any plausible reason behind this?

Cheers!
Sateesh

[Reinhold Birkenfeld]

Sateesh wrote:

Hi,
I am a beginner in Python, and am wondering what is it about the indentation
in Python, without which python scripts do not work properly.
Why can't the indentation not so strict so as to give better freedom to the
user?
Is there any plausible reason behind this?

Yes. It's about readability.

In many languages, such as C or Perl, you can write readable code, but
you can also squeeze your code in as few lines as possible, resulting in
hard to read, hard to maintain, hard to debug code[1]. Whenever I
translate a Perl script into Python, I end up with about 25-40% more
lines, but the script is much more readable than the Perl counterpart
(mostly, of course, because of the lacking $'s ;).

Furthermore, most languages don't force indentation and use { } or
begin-end syntax. In Python, you have to indent your code properly,
which leads to clear structure.

I know how you feel when you are confronted with Python's indentation
system at first: Oh my god, the language is using significant
whitespace. As most of us come from a C background, an absolute
free-form language, this may seem like an unacceptable restraint, but as
you write code, it flows naturally, as if you ever hadn't written
something else. And, you don't have to write "end" :)

Reinhold

[1] This doesn't mean that you cannot write ununderstandable code in
Python... *grin*

--
Wenn eine Linuxdistribution so wenig brauchbare Software wie Windows
mitbrächte, wäre das bedauerlich. Was bei Windows der Umfang eines
"kompletten Betriebssystems" ist, nennt man bei Linux eine Rescuedisk.
-- David Kastrup in de.comp.os.unix.linux.misc

[Brian Quinlan]

Sateesh wrote:

Why can't the indentation not so strict so as to give better freedom to the
user?

Can you specify what desirable construction Python is denying you? Or
are you talking about freedom in the abstract?

Cheers,
Brian

[Sateesh]

I surely understand the importance of indentation, but as you see there are
beautification tools that can be used to beautiy the C code. Also
indentation is based upon ones style of coding, and I feel somewhat
restricted when the language itself restricts someone to code in a
particular way.

Sateesh

"Brian Quinlan" <br***@sweetapp.com> wrote in message
news:ma************************************@python .org...

Sateesh wrote:

Why can't the indentation not so strict so as to give better freedom to the user?

Can you specify what desirable construction Python is denying you? Or
are you talking about freedom in the abstract?

Cheers,
Brian

[Brian Quinlan]

Sateesh wrote:

I surely understand the importance of indentation, but as you see there are
beautification tools that can be used to beautiy the C code.
I'm not sure why this is relevant.
Also indentation is based upon ones style of coding, and I feel somewhat
restricted when the language itself restricts someone to code in a
particular way.

Which is why I asked you to name a desirable code construction that
Python denies you due to it's indentation rules. If, for example, you
find the following style compelling:

if condition:
clause1
else:
clause2

Then Python is, indeed, restricting you. So could you provide an actual
example where Python is keeping you from using a style that you find
desirable?

Cheers,
Brian

[Jeff Epler]

I doubt anybody but you has ever wondered about this, and if they have
the answers probably don't appear in a FAQ, the tutorial, "google"
or "google groups" searches, or any of the books published about the
Python language.

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA6+SlJd01MZaTXX0RAgKgAJ9JwwpYkjy5DIGU6p5QfK 0m7/0lowCfeyDE
ncX4vs1DCCyfgHW5GbCnUMk=
=y1+2
-----END PGP SIGNATURE-----

[Reinhold Birkenfeld]

Sateesh wrote:

I surely understand the importance of indentation, but as you see there are
beautification tools that can be used to beautiy the C code. Also
indentation is based upon ones style of coding, and I feel somewhat
restricted when the language itself restricts someone to code in a
particular way.

That is what I wrote about. In the beginning, you think of the
indentation as a restriction. Later, you will be glad about it, and you
will not desire to structure your code otherwise.

Reinhold

--
Wenn eine Linuxdistribution so wenig brauchbare Software wie Windows
mitbrächte, wäre das bedauerlich. Was bei Windows der Umfang eines
"kompletten Betriebssystems" ist, nennt man bei Linux eine Rescuedisk.
-- David Kastrup in de.comp.os.unix.linux.misc

[Brian Elmegaard]

"Sateesh" <ex****************@nokia.com> writes:

I surely understand the importance of indentation, but as you see there are
beautification tools that can be used to beautiy the C code. Also
indentation is based upon ones style of coding, and I feel somewhat
restricted when the language itself restricts someone to code in a
particular way.

It is probably a matter of taste, but I don't like all the {} and ;
in c and the like.

Indentation in python may be done as you like, just keep it aligned
in the same block.

--
Brian (remove the sport for mail)
http://www.et.dtu.dk/staff/be

[Sateesh]

I think I would be able to better appreciate Python after I go ahead with
some programming first.

Thanks for the insights!

Sateesh
"Brian Quinlan" <br***@sweetapp.com> wrote in message
news:ma************************************@python .org...

Sateesh wrote:

I surely understand the importance of indentation, but as you see there are beautification tools that can be used to beautiy the C code.

I'm not sure why this is relevant.

Also indentation is based upon ones style of coding, and I feel somewhat
restricted when the language itself restricts someone to code in a
particular way.

Which is why I asked you to name a desirable code construction that
Python denies you due to it's indentation rules. If, for example, you
find the following style compelling:

if condition:
clause1
else:
clause2

Then Python is, indeed, restricting you. So could you provide an actual
example where Python is keeping you from using a style that you find
desirable?

Cheers,
Brian

[Ville Vainio]

>>>>> "Sateesh" == Sateesh <ex****************@nokia.com> writes:

Sateesh> Why can't the indentation not so strict so as to give
Sateesh> better freedom to the user?

You already have all the freedom you need. You can indent with 1
space, or 56 spaces if that strikes your fancy. Why would you want the
freedom to indent inconsistently?

Sateesh> Is there any plausible reason behind this?

You should search the newsgroup archives (in google), there are
probably megabytes of discussion on this matter.

--
Ville Vainio http://tinyurl.com/2prnb

[Grant Edwards]

On 2004-07-07, Reinhold Birkenfeld <re************************@wolke7.net> wrote:

I am a beginner in Python, and am wondering what is it about
the indentation in Python, without which python scripts do not
work properly. Why can't the indentation not so strict so as
to give better freedom to the user? Is there any plausible
reason behind this?

Yes. It's about readability.

In many languages, such as C or Perl, you can write readable code, but
you can also squeeze your code in as few lines as possible, resulting in
hard to read, hard to maintain, hard to debug code[1]. Whenever I
translate a Perl script into Python, I end up with about 25-40% more
lines, but the script is much more readable than the Perl counterpart
(mostly, of course, because of the lacking $'s ;).

Compare C and Python:

In C, we have 10 lines

if (condition)
{
doThis();
doThat();
}
else
{
doWhatever();
andSoOn();
}

Which translates into 6 lines of Python:

if condition:
doThis()
doThat()
else:
doWhatever()
andSoOn()

Many fewer lines of space are wasted on delimiters. That means
you're more likely to have the entire logical "block" on the
screen at once. That means fewer bugs.

[Not to mention it takes about 1/4 to 1/3 of the actual lines
of code to accomplish the same amount of work.]

--
Grant Edwards grante Yow! Thank god!!... It's
at HENNY YOUNGMAN!!
visi.com

[Grant Edwards]

On 2004-07-07, Sateesh <ex****************@nokia.com> wrote:

I surely understand the importance of indentation, but as you see there are
beautification tools that can be used to beautiy the C code. Also
indentation is based upon ones style of coding, and I feel somewhat
restricted when the language itself restricts someone to code in a
particular way.

All languages are restrictive. C requires blocks are delimited
by {} and statements by ;. Python isn't more restrictive, it
just has _different_ restrictions.

--
Grant Edwards grante Yow! What I want to find
at out is -- do parrots know
visi.com much about Astro-Turf?

[Peter Hansen]

Ville Vainio wrote:

>>"Sateesh" == Sateesh <ex****************@nokia.com> writes:

Sateesh> Why can't the indentation not so strict so as to give
Sateesh> better freedom to the user?

You already have all the freedom you need. You can indent with 1
space, or 56 spaces if that strikes your fancy. Why would you want the
freedom to indent inconsistently?

Oh, believe me, some people do want that (though, I hope, not
Sateesh... he sounds more sensible :-). I once had a fellow
working for me who, as it turned out, would indent effectively
arbitrary amounts each time he started a new block. We
were so astounded that several of us clustered around him to
watch him do it. He was quite amenable to the audience, too,
as he saw nothing wrong with it.

He would type (this was in C), say, an 'if' statement and its
expression. Then he would hit Enter and hold down the space
bar for a second or two. Generally he'd end up at least five
or ten spaces past the previous line's indentation. Sometimes
it was 25 spaces. The blocks for the 'if' and the 'else'
would rarely align, and if they did it was mere serendipity.

As it shortly turned out, the fellow was an iceberg, and
once we discovered the other 90% lurking below the surface,
and the seriously negative effect it had on his code (which
was all but unreadable to the rest of us, not to mention
just plain scary bad), we ditched him pretty quick.

The ironic thing is that he could just as easily have done
this with Python -- he was at least consistent within a
block...

-Peter

[Nikola Plejic]

Sateesh wrote:

I surely understand the importance of indentation, but as you see there are
beautification tools that can be used to beautiy the C code. Also
indentation is based upon ones style of coding, and I feel somewhat
restricted when the language itself restricts someone to code in a
particular way.

Sateesh

Huh, then C also limits you in a way... You have to constantly open and
close those curly braces. I'd be much better if I wouldn't have to do
that, but I have to get along with it (N.B. - I'm not a C programmer so
don't get me wrong :)).

Instead of { and } you have indentation... IMHO, that's a much more
"natural" way of defining blocks of code. You'll see, you'll get used to
it. It often results in writing *much* cleaner code in other languages,
too. At least in my case.

--
regards, [ mailto: zweistein at ftml dot net ]
Nikola [ http://hades.indivia.net/ ]

[Peter Maas]

Sateesh schrieb:

I surely understand the importance of indentation, but as you see there are
beautification tools that can be used to beautiy the C code. Also
indentation is based upon ones style of coding, and I feel somewhat
restricted when the language itself restricts someone to code in a
particular way.

You are only restricted if you want leading whitespace independent
from the block structure of your code. Formatting discussions among
C-Programmers concentrate on these topics:

1. How deep to indent:
this can be freely chosen in Python as well.

2. How to set brackets:
This issue is resolved automatically in Python. :)

Mit freundlichen Gruessen,

Peter Maas

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel [phone]
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
-------------------------------------------------------------------

[Steve Holden]

Sateesh wrote:

I think I would be able to better appreciate Python after I go ahead with
some programming first.
A profound conclusion, that has taken many others much longer to arrive at!
Thanks for the insights!

Sateesh

regards
Steve

[Jacek Generowicz]

"Sateesh" <ex****************@nokia.com> writes:

Hi,
I am a beginner in Python, and am wondering what is it about the indentation
in Python, without which python scripts do not work properly.
Why can't the indentation not so strict so as to give better freedom to the
user?
Is there any plausible reason behind this?

def ask(lang, noise):
print """I am a beginner in %s, and am wondering what is it about the %s in
%s, without which %s programs do not work properly.
Why can't the %s not so strict so as to give better freedom to
the user?
Is there any plausible reason behind this?""" % (lang, noise, lang, lang, noise)
print

for l,n in [['C', '{,} and ;'],
['C++', '{,} and ;'],
['Java', '{,} and ;'],
['Pascal', 'begin and end'],
['Lisp', '( and )'],
['Perl', '!@#*$&!@$#']]:
ask(l,n)

keywords: parody, irony

[Reinhold Birkenfeld]

Grant Edwards wrote:

On 2004-07-07, Reinhold Birkenfeld <re************************@wolke7.net> wrote:

I am a beginner in Python, and am wondering what is it about
the indentation in Python, without which python scripts do not
work properly. Why can't the indentation not so strict so as
to give better freedom to the user? Is there any plausible
reason behind this?
Yes. It's about readability.

In many languages, such as C or Perl, you can write readable code, but
you can also squeeze your code in as few lines as possible, resulting in
hard to read, hard to maintain, hard to debug code[1]. Whenever I
translate a Perl script into Python, I end up with about 25-40% more
lines, but the script is much more readable than the Perl counterpart
(mostly, of course, because of the lacking $'s ;).

Compare C and Python:

In C, we have 10 lines

if (condition)
{
doThis();
doThat();
}
else
{
doWhatever();
andSoOn();
}

Well, one could apply another coding style in this example:

if (condition) {
doThis();
doThat();
} else {
doWhatever();
andSoOn();
}

which only takes 7 lines and is not much less readable. But I agree with
you!
Which translates into 6 lines of Python:

if condition:
doThis()
doThat()
else:
doWhatever()
andSoOn()

Many fewer lines of space are wasted on delimiters. That means
you're more likely to have the entire logical "block" on the
screen at once. That means fewer bugs.

[Not to mention it takes about 1/4 to 1/3 of the actual lines
of code to accomplish the same amount of work.]

ACK.

Reinhold

--
Wenn eine Linuxdistribution so wenig brauchbare Software wie Windows
mitbrächte, wäre das bedauerlich. Was bei Windows der Umfang eines
"kompletten Betriebssystems" ist, nennt man bei Linux eine Rescuedisk.
-- David Kastrup in de.comp.os.unix.linux.misc

[Reinhold Birkenfeld]

Peter Hansen wrote:

As it shortly turned out, the fellow was an iceberg, and
once we discovered the other 90% lurking below the surface,
and the seriously negative effect it had on his code (which
was all but unreadable to the rest of us, not to mention
You mean "all but readable"?
just plain scary bad), we ditched him pretty quick.

Reinhold
--
Wenn eine Linuxdistribution so wenig brauchbare Software wie Windows
mitbrächte, wäre das bedauerlich. Was bei Windows der Umfang eines
"kompletten Betriebssystems" ist, nennt man bei Linux eine Rescuedisk.
-- David Kastrup in de.comp.os.unix.linux.misc

[Grant Edwards]

On 2004-07-07, Reinhold Birkenfeld <re************************@wolke7.net> wrote:

In C, we have 10 lines

if (condition)
{
doThis();
doThat();
}
else
{
doWhatever();
andSoOn();
}
Well, one could apply another coding style in this example:

if (condition) {
doThis();
doThat();
} else {
doWhatever();
andSoOn();
}

which only takes 7 lines and is not much less readable.

Maybe for some people, but I've never been able to read C code
like that. I always have to run it through 'indent' to put the
braces on separate lines. When working on code that requires
'old-style' indentation, the process is:

1) run it through indent so I can read it
2) edit/compile/test
3) run it through indent again to restore old indentation
But I agree with you!

:)

--
Grant Edwards grante Yow! It's a lot of fun
at being alive... I wonder if
visi.com my bed is made?!?

[Peter Hansen]

Reinhold Birkenfeld wrote:

Peter Hansen wrote:

As it shortly turned out, the fellow was an iceberg, and
once we discovered the other 90% lurking below the surface,
and the seriously negative effect it had on his code (which
was all but unreadable to the rest of us, not to mention

You mean "all but readable"?

I actually did mean "all but unreadable", and I think that is
an English idiom that I used correctly (in effect, it means
"nearly unreadable").

In any case, I was being too kind: his code was completely
unreadable to the rest of us... :-)

-Peter

[John Roth]

"Sateesh" <ex****************@nokia.com> wrote in message
news:aN*******************@news1.nokia.com...

Hi,
I am a beginner in Python, and am wondering what is it about the indentation in Python, without which python scripts do not work properly.
Why can't the indentation not so strict so as to give better freedom to the user?
Is there any plausible reason behind this?
Readability. Some people feel it confines them,
they tend to go to other languages.

John Roth
Cheers!
Sateesh

[Reinhold Birkenfeld]

Peter Hansen wrote:

Reinhold Birkenfeld wrote:

Peter Hansen wrote:

As it shortly turned out, the fellow was an iceberg, and
once we discovered the other 90% lurking below the surface,
and the seriously negative effect it had on his code (which
was all but unreadable to the rest of us, not to mention
You mean "all but readable"?

I actually did mean "all but unreadable", and I think that is
an English idiom that I used correctly (in effect, it means
"nearly unreadable").

Ok, then it's my lousy English... I though of "alles, außer lesbar".
In any case, I was being too kind: his code was completely
unreadable to the rest of us... :-)

*g* I know what you're speaking of...

Reinhold

--
Wenn eine Linuxdistribution so wenig brauchbare Software wie Windows
mitbrächte, wäre das bedauerlich. Was bei Windows der Umfang eines
"kompletten Betriebssystems" ist, nennt man bei Linux eine Rescuedisk.
-- David Kastrup in de.comp.os.unix.linux.misc

[Steve Lamb]

On 2004-07-07, Sateesh <ex****************@nokia.com> wrote:

I am a beginner in Python, and am wondering what is it about the indentation
in Python, without which python scripts do not work properly.
Why can't the indentation not so strict so as to give better freedom to the
user?
Is there any plausible reason behind this?

Could you give an example of what you feel would not be possible in
Python? I have found that when most people hear "significant white space"
they mistakeningly feel that it is like older languages which had the same.
It is not. Thus far I have not found any indention of code that I would want
to do in another language (within reason) which is not possible in Python.

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Tor Iver Wilhelmsen]

"Sateesh" <ex****************@nokia.com> writes:

Why can't the indentation not so strict so as to give better freedom to the
user?

It's a core syntactical feature of the language. Your request is like
asking, say, a C family language to adopt BEGIN and END instead of
those weird braces, because you're used to it from Pascal.

[Istvan Albert]

Sateesh wrote:

Why can't the indentation not so strict so as to give better freedom to the
user?
Is there any plausible reason behind this?

What will bother you even more is that the "official"
recommendation is that you should be using spaces to
indent not tabs... the reason appears to be that tabs
might not copy properly from some terminal windows...

I like python very much, but every time I see a space indented
module the first thing I do is to replace the spaces with
tabs.

I noticed that beginners like to indent more while experts
indent less. Once your eye is trained 2 levels might
be enough. OTOH it depends on the project, with many nested loops
you're better off with wider display. IMHO a display of
3 spaces is the best....

But if you stick with the "official" recommendation
then you have to press four spaces or four deletes on the first level,
eight on the second etc... to align stuff...

Yeah, yeah I know that this or that editor has a shortcut enabled via
CTRL+ALT+INSERT+SPACE+double-click+W and that will do the job in one
keystroke, but sometimes you need to work with unfamiliar editors
and odd circumstances and then the whole spaces vs tabs argument
becomes extremely relevant and the wide adoption of "spaces"
makes it a drag.

one more thing to consider...

I.

[Peter Hansen]

Istvan Albert wrote:

What will bother you even more is that the "official"
recommendation is that you should be using spaces to
indent not tabs... the reason appears to be that tabs
might not copy properly from some terminal windows...
Actually, that's only one of several reasons. Another is
that there is no universally agreed-upon definition of how
much indentation is intended for the ASCII TAB character,
which leads to several problems including ambiguity when
spaces and tabs are mixed.

Ambiguity sucks but a SPACE is a SPACE is a SPACE.
I like python very much, but every time I see a space indented
module the first thing I do is to replace the spaces with
tabs.
I had an urge to do that really early on, from some leftover
feeling that I was wasting hard drive space. My advice is
to get over it. You'll sleep better, not worrying about all
the SPACE-infested code out there in the world that you
haven't had a chance to "fix". :-)
But if you stick with the "official" recommendation
then you have to press four spaces or four deletes on the first level,
eight on the second etc... to align stuff...
I can't imagine anyone actually thinks this is what they really
are expected to do. If your editor is really broken, use single
spaces in the interim, while you find a non-broken one.
Yeah, yeah I know that this or that editor has a shortcut enabled via
CTRL+ALT+INSERT+SPACE+double-click+W and that will do the job in one
keystroke,

*Any* decent editor can be configured to inject spaces up to the
next defined tab-stop when TAB is hit. By definition, therefore,
any editor that cannot is broken.

-Peter

[Jarek Zgoda]

Peter Hansen <pe***@engcorp.com> pisze:

*Any* decent editor can be configured to inject spaces up to the
next defined tab-stop when TAB is hit. By definition, therefore,
any editor that cannot is broken.

Isn't "obsolete" an antonime for "decent", rather than "broken"?

--
Jarek Zgoda
http://jpa.berlios.de/

[bruno modulix]

Reinhold Birkenfeld a écrit :

Grant Edwards wrote:
(snip about 'why significative whitespace')

Yes. It's about readability.

(snip)Compare C and Python:

In C, we have 10 lines

if (condition)
{
doThis();
doThat();
}
else
{
doWhatever();
andSoOn();
}

Well, one could apply another coding style in this example:

if (condition) {
doThis();
doThat();
} else {
doWhatever();
andSoOn();
}

which only takes 7 lines and is not much less readable.

For me it's as absolutely unreadable as the first snippet.
The only truely correct layout being (of course !-) :

if (condition)
{
doThis();
doThat();
}
else
{
doWhatever();
andSoOn();
}
But I agree with
you!

I do too. The fact is that there is no brace-and-indent-style-war with
Python !-)

Bruno

[Reinhold Birkenfeld]

bruno modulix wrote:

But I agree with
you!

I do too. The fact is that there is no brace-and-indent-style-war with
Python !-)

As we can see a few threads later, it is replaced by the
tabs-or-spaces-war...

Reinhold

--
Wenn eine Linuxdistribution so wenig brauchbare Software wie Windows
mitbrächte, wäre das bedauerlich. Was bei Windows der Umfang eines
"kompletten Betriebssystems" ist, nennt man bei Linux eine Rescuedisk.
-- David Kastrup in de.comp.os.unix.linux.misc

[bruno modulix]

Jacek Generowicz a écrit :

"Sateesh" <ex****************@nokia.com> writes:

Hi,
I am a beginner in Python, and am wondering what is it about the indentation
in Python, without which python scripts do not work properly.
Why can't the indentation not so strict so as to give better freedom to the
user?
Is there any plausible reason behind this?

def ask(lang, noise):
print """I am a beginner in %s, and am wondering what is it about the %s in
%s, without which %s programs do not work properly.
Why can't the %s not so strict so as to give better freedom to
the user?
Is there any plausible reason behind this?""" % (lang, noise, lang, lang, noise)
print

for l,n in [['C', '{,} and ;'],
['C++', '{,} and ;'],
['Java', '{,} and ;'],
['Pascal', 'begin and end'],
['Lisp', '( and )'],
['Perl', '!@#*$&!@$#/\'],

['PHP', '$ and {,} and ;']]: ask(l,n)

keywords: parody, irony

Keyboard !

(5 minutes later)

Is it GPL'ed ?-)

Bruno

[Steve Lamb]

On 2004-07-07, Peter Hansen <pe***@engcorp.com> wrote:

Istvan Albert wrote:

Yeah, yeah I know that this or that editor has a shortcut enabled via
CTRL+ALT+INSERT+SPACE+double-click+W and that will do the job in one
keystroke,

*Any* decent editor can be configured to inject spaces up to the
next defined tab-stop when TAB is hit. By definition, therefore,
any editor that cannot is broken.

What Istvan is using is better known, to me at least, as "the vi
argument". IE, it was best for people to learn vi over another editor because
one could be stuck with nothing but vi to do editing with since all unixes
came with vi stock. Whatever would someone do if they were incapable of using
their preferred editor and stuck *only* with vi!?

Nevermind that there are now several well used flavors of unix which do
not come stock with vi or, at the very least, only vi. And some of the
situations that the people would create. "What if you only had a laptop, an
install disc for intel solaris and were stuck on a stranded isle with no
network access to get anything else!? You really need to conserve battery
power so you can't waste time learning vi then but you need it to write the
perfect program to calculate the best method of communication using firewood.
YOU DON'T KNOW VI!!! WHAT WOULD YOU DO!!!!! AIYEEEEEE!!!!" Ok, I may be
exagerrating a tiny bit but only a tiny bit.

Personally I've not been in a situation where I haven't had a decent
editor to program with in the past decade or two. I use spaces for just the
reason you gave; a SPACE is a SPACE is a SPACE. Anyone who's worried about
how many keystrokes they're going to expend because they're programming Python
on a laptop on a deserted isle in the middle of the pacific with only notepad
really needs to reexamine their priorities.

Oh, and for the record, I can tweak the collective noses of the vi
zealots who came up with such absurd and convoluted reasonings on why everyone
simply MUST learn vi because I use vim. ;)

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Steve Lamb]

On 2004-07-07, Reinhold Birkenfeld <re************************@wolke7.net> wrote:

As we can see a few threads later, it is replaced by the
tabs-or-spaces-war...

Not really. First off if one follows the offical coding style it is 4
spaces. Go against it at your own peril. The braces-placement war isn't
replaced with the tabs-or-spaces war. That presumes the tab-or-spaces war
doesn't exist side-by-side with the braces-placement war. We just notice it
more since we don't have the braces-placement war to detract us. :)

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[bruno modulix]

Tor Iver Wilhelmsen a écrit :

"Sateesh" <ex****************@nokia.com> writes:

Why can't the indentation not so strict so as to give better freedom to the
user?

It's a core syntactical feature of the language. Your request is like
asking, say, a C family language to adopt BEGIN and END instead of
those weird braces, because you're used to it from Pascal.

Quite easy :
#define BEGIN {
#define END }

Bruno

[Christopher Weimann]

On 07/07/2004-08:36PM, Steve Lamb wrote:

What Istvan is using is better known, to me at least, as "the vi
argument". IE, it was best for people to learn vi over another editor because
one could be stuck with nothing but vi to do editing with since all unixes
came with vi stock.

Thats not the reason to learn vi, its the reason to learn ed :)

[Dan Bishop]

Grant Edwards <gr****@visi.com> wrote in message news:<sl******************@grante.rivatek.com>...

On 2004-07-07, Reinhold Birkenfeld <re************************@wolke7.net> wrote:

I am a beginner in Python, and am wondering what is it about
the indentation in Python, without which python scripts do not
work properly. Why can't the indentation not so strict so as
to give better freedom to the user? Is there any plausible
reason behind this?

Yes. It's about readability.

In many languages, such as C or Perl, you can write readable code, but
you can also squeeze your code in as few lines as possible, resulting in
hard to read, hard to maintain, hard to debug code[1]. Whenever I
translate a Perl script into Python, I end up with about 25-40% more
lines, but the script is much more readable than the Perl counterpart
(mostly, of course, because of the lacking $'s ;).

Compare C and Python:

In C, we have 10 lines [compared to 6 in Python]

if (condition)
{
doThis();
doThat();
}
else
{
doWhatever();
andSoOn();
}

Only because you're using an inefficient brace style.

The style I use writes it as:

if (condition) {
doThis();
doThat();
} else {
doWhatever();
andSoOn();
}

which is 7 lines, only 1 more than the Python version.

But this does demonstrate an advantage of Python: No arguments over
where to put braces :-)

[Istvan Albert]

Peter Hansen wrote:

Ambiguity sucks but a SPACE is a SPACE is a SPACE.
Is there a reason why a TAB is not a TAB is not a TAB?
*Any* decent editor can be configured to inject spaces up to the
next defined tab-stop when TAB is hit. By definition, therefore,
any editor that cannot is broken.

Is it really that trivial to set up an editor so that when one hits
delete/backspace to 'un-align' a line of code it deletes as
many space characters as the soft-tab has inserted?

I don't think so.

Istvan.

[Jarek Zgoda]

Istvan Albert <ia*****@mailblocks.com> pisze:

Ambiguity sucks but a SPACE is a SPACE is a SPACE.

Is there a reason why a TAB is not a TAB is not a TAB?

Because TAB is TAB and not 8 * SPACE nor 4 * SPACE nor 2 * SPACE. In
editor you don't see a TAB, you see 8 * SPACE or 4 * SPACE or 2 * SPACE
or any number of spaces you set in your editor options. There's no
display character for TAB, it is substituted by SPACES.

As you see, TAB is down, while spaces are up. Resistance is futile. You
will be assimilated.

--
Jarek Zgoda
http://jpa.berlios.de/

[Ville Vainio]

>>>>> "Istvan" == Istvan Albert <ia*****@mailblocks.com> writes:

Istvan> Is it really that trivial to set up an editor so that when
Istvan> one hits delete/backspace to 'un-align' a line of code it
Istvan> deletes as many space characters as the soft-tab has
Istvan> inserted?

Emacs python-mode does it.

Lesser editors often achieve the same effect by shift-tab.

--
Ville Vainio http://tinyurl.com/2prnb

[Mike C. Fletcher]

Jarek Zgoda wrote:

Istvan Albert <ia*****@mailblocks.com> pisze:

Ambiguity sucks but a SPACE is a SPACE is a SPACE.

Is there a reason why a TAB is not a TAB is not a TAB?

Because TAB is TAB and not 8 * SPACE nor 4 * SPACE nor 2 * SPACE. In
editor you don't see a TAB, you see 8 * SPACE or 4 * SPACE or 2 * SPACE
or any number of spaces you set in your editor options. There's no
display character for TAB, it is substituted by SPACES.

As you see, TAB is down, while spaces are up. Resistance is futile. You
will be assimilated.

Nope. People have been telling me to use spaces in my Python for
*years*, and I'm nowhere near assimilated. The number of silly
occasions where hitting <del> or <backspace> to remove a tab works where
the editor doesn't pick up an attempt to remove 4-or-so-spaces keeps me
going back to the simple "a tab is an indent" approach. The simple fact
( ;) I know, it's a holy war, there are no facts, but I feel like
tweaking the spacies) is that having 3 or 4 or 2 or 8 characters
represent the concept "indentation level" is just silly when you've got
the single character representation available.

Oh, and decent editors (hint: PythonWin rules), that is, those based on
Scintilla (almost every Python-specific IDE) *do* have a character for
displaying <tab>, it's an elongated arrow that looks surprisingly like
the arrow on my keyboard's tab key :) . BTW the fact that I can set the
display of an indentation level (tab) to whatever width I like is a
*benefit* :) .

Of course, normally I just tell people telling me to switch "sure, I
could change, but I have more Python code than you[1], so *you* conform"
;) ,
Mike

[1] And, generally speaking, this is true, as anyone who has written
more Python is almost certainly one of us old-timers and would never
think of starting this silly thread *again*... :)

________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://members.rogers.com/mcfletch/
blog: http://zope.vex.net/~mcfletch/plumbing/

[Christopher T King]

On Wed, 7 Jul 2004, Jarek Zgoda wrote:

Istvan Albert <ia*****@mailblocks.com> pisze:

Ambiguity sucks but a SPACE is a SPACE is a SPACE.

Is there a reason why a TAB is not a TAB is not a TAB?

Because TAB is TAB and not 8 * SPACE nor 4 * SPACE nor 2 * SPACE. In
editor you don't see a TAB, you see 8 * SPACE or 4 * SPACE or 2 * SPACE
or any number of spaces you set in your editor options. There's no

Which is exactly why I use tabs -- if I don't like the indentation width,
I just change and option and BAM! it's changed! Whereas with spaces, I'm
stuck with looking at one- or eight- character indents, rather than my
preferred tab width setting.

My other reason for using tabs is that my preferred editor (JOE)
couldn't unindent space-based indents prior to its 3.0 release (very
recent). Now my excuse is WHAT IF I HAVE TO USE NOTEPAD?!?! :)

[Ubergeek]

Mike C. Fletcher wrote:

Jarek Zgoda wrote:

Istvan Albert <ia*****@mailblocks.com> pisze:

Ambiguity sucks but a SPACE is a SPACE is a SPACE.
Is there a reason why a TAB is not a TAB is not a TAB?

Because TAB is TAB and not 8 * SPACE nor 4 * SPACE nor 2 * SPACE. In
editor you don't see a TAB, you see 8 * SPACE or 4 * SPACE or 2 * SPACE
or any number of spaces you set in your editor options. There's no
display character for TAB, it is substituted by SPACES.

As you see, TAB is down, while spaces are up. Resistance is futile. You
will be assimilated.

Nope. People have been telling me to use spaces in my Python for
*years*, and I'm nowhere near assimilated. The number of silly
occasions where hitting <del> or <backspace> to remove a tab works where
the editor doesn't pick up an attempt to remove 4-or-so-spaces keeps me
going back to the simple "a tab is an indent" approach. The simple fact
( ;) I know, it's a holy war, there are no facts, but I feel like
tweaking the spacies) is that having 3 or 4 or 2 or 8 characters
represent the concept "indentation level" is just silly when you've got
the single character representation available.

IMHO, it doesn't make that much difference if you use all tabs or you
use all spaces for your indentation if you're the only one that ever
edits the source file. The problem comes in if the two ever get mixed
in the same file, which is particularly problematic if you have more
than one person working on a file or if you share some code as open source.

If you use tabs in your source with a 4-space width and I make a mod to
one of your files when I have my editor configured to insert 4 spaces
for indent, it'll look the same on the screen but Python will get very
unhappy. Because all blocking in Python is based on lines with
identical amounts of indentation, Python has to convert all those tabs
to some amount of spaces in order to calculate indentation. Since
Python has no idea what tab width you have set in your editor, it has to
assume a fixed size for tabs (which, IIRC, is 8 spaces). Because of
this, your 4-space wide tab and my 4 real spaces represent different
indentation levels and the blocking of the code is now hosed.

The advantage of using all spaces is that no matter what editor you load
a source file in or what your tab-width configuration is, it is
guaranteed that a human being and the Python interpreter will both see
the indentation the same way.

[Peter Hansen]

Steve Lamb wrote:

What Istvan is using is better known, to me at least, as "the vi
argument". IE, it was best for people to learn vi over another editor because
one could be stuck with nothing but vi to do editing with since all unixes
came with vi stock. Whatever would someone do if they were incapable of using
their preferred editor and stuck *only* with vi!?

Nevermind that there are now several well used flavors of unix which do
not come stock with vi or, at the very least, only vi. And some of the
situations that the people would create. "What if you only had a laptop, an
install disc for intel solaris and were stuck on a stranded isle with no
network access to get anything else!? You really need to conserve battery
power so you can't waste time learning vi then but you need it to write the
perfect program to calculate the best method of communication using firewood.
YOU DON'T KNOW VI!!! WHAT WOULD YOU DO!!!!! AIYEEEEEE!!!!" Ok, I may be
exagerrating a tiny bit but only a tiny bit.

I'm actually pretty inept with vi (or vim), to the point that I don't
actually know how to configure it for use with Python. And every
now and then, I'm forced to use it. When that happens, I find
that writing my little one-off (since inevitably that's what it
is, even if it's to figure out how to use smoke signals on a
desert island) is best done with single spaces. Bingo-bango, no
typing disadvantage over TABs... even better, I get to use
my *thumb*, which is much stronger than my middle finger, and
don't need to move my wrist at all, decreasing the effect of the
whole process on my carpal tunnel syndrome.

Basically, the "vi argument" has no merit, since the only times
one can't get access to a decent editor, preconfigured to do the
Right Thing with Python, is an emergency, and in an emergency,
single spaces work as well as tabs. End of argument. :-) (No,
really, that will stop the discussion permanently. Really!)

-Peter

[Steve Lamb]

On 2004-07-07, Dan Bishop <da*****@yahoo.com> wrote:

The style I use writes it as:

if (condition) {
doThis();
doThat();
} else {
doWhatever();
andSoOn();
} which is 7 lines, only 1 more than the Python version. But this does demonstrate an advantage of Python: No arguments over
where to put braces :-)

Damn skippy. 'round these parts it would look like this:

if (condition) {
doThis();
doThat();
}
else {
doWhatever();
andSoOn();
}

8 lines. But that's because I never understood why anyone would
willingly use the '} else {' construct since the else is ovten obscured.
Keyword opens the block, } ends the block, never put a block open and close on
the same line.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Steve Lamb]

On 2004-07-07, Istvan Albert <ia*****@mailblocks.com> wrote:

Is there a reason why a TAB is not a TAB is not a TAB?
Yes. Name the number of spaces a TAB should translate into.

That was easy. Now explain why your answer is right and the next guy's
answer, which is different than yours, is wrong.

Oh, not so easy, eh? TAB, by it's very nature, is a variable and
configurable width. A SPACE is not.
Is it really that trivial to set up an editor so that when one hits
delete/backspace to 'un-align' a line of code it deletes as
many space characters as the soft-tab has inserted? I don't think so.

Uhm, yes, it is. With vim part of my configuration when loading Python
files:
au FileType python set autoindent smartindent et sts=4 sw=4 tw=80 fo=croq

Translates into:

Autoindent on
Smartindent on
Expandtab on
SoftTabStop 4 spaces
ShiftWidth 4 spaces
TextWidth 80 spaces
FormatOptions
c - auto-wrap comments, automatically inserting current comment character
r - Automatically insert current comment character after hitting enter in
in insert mode
o - Automatically insert current comment character after hitting o or O in
command mode.
q - allow formatting of comments with gq (IE, reflow and keep comment
characters at the front of the line).

Where's the magic? Here:

-----
'softtabstop' 'sts' number (default 0)
local to buffer
{not in Vi}
Number of spaces that a <Tab> counts for while performing editing
operations, like inserting a <Tab> or using <BS>. It "feels" like
<Tab>s are being inserted, while in fact a mix of spaces and <Tab>s is
used. This is useful to keep the 'ts' setting at its standard value
of 8, while being able to edit like it is set to 'sts'. However,
commands like "x" still work on the actual characters.
When 'sts' is zero, this feature is off.
-----

Number of spaces that a <Tab> counts for while performing editing
operations like....<BS> (Backspace). IE, I set STS to 4. I hit tab, 4 spaces
are inserted. I hit backspace, 4 spaces are removed. It's just that simple.

As for alignment operations ShiftWidth is used for << and >> which are
used to (de)indent blocks of code.

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Peter Hansen]

Christopher T King wrote:

My other reason for using tabs is that my preferred editor (JOE)
couldn't unindent space-based indents prior to its 3.0 release (very
recent). Now my excuse is WHAT IF I HAVE TO USE NOTEPAD?!?! :)

On what planet is *anyone* forced to use Notepad for real
development? That is, for anything other than emergency
one-offs?

-Peter

[Steve Lamb]

On 2004-07-07, Christopher T King <sq******@WPI.EDU> wrote:

My other reason for using tabs is that my preferred editor (JOE)
couldn't unindent space-based indents prior to its 3.0 release (very
recent). Now my excuse is WHAT IF I HAVE TO USE NOTEPAD?!?! :)

You slit your wrists with a ceremonial butter knife?

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[David Bolen]

Steve Lamb <gr**@despair.dmiyu.org> writes:

8 lines. But that's because I never understood why anyone would
willingly use the '} else {' construct since the else is ovten
obscured. Keyword opens the block, } ends the block, never put a
block open and close on the same line.

Oh, I thought I wouldn't contribute to this thread, but what the hey...

I certainly willingly use the "} else {" construct - probably to me
because it stands out quite well and doesn't add additional noise
along the left edge (the } and else on separate lines feels jarring to
my eyes). There's plenty of density in the "} else {" (as opposed to
a simple closing brace) to draw my eye.

Clearly it's an "in the eye of the beholder" thing. I will admit to
being a K&R "one true brace style" guy. Maybe from having learned C
with K&R, but possibly a subconcious effort to minimize my brace
impact (minimize wasted empty brace only lines and impact on the
visual blocks I was creating) on what was otherwise an indentation
based block format I was trying to express. Little did I know I
really just wanted Python :-)

Interestingly, I never even really considered the else and next
opening brace ("else {") on its own line as an option - the folks that
I've seen use else starting on its own line also tend to be those that
prefer the Allman/BSD style of braces, in which case else would be
alone on the line with the closing and opening braces on their own
lines above and below it. I don't mind BSD style, but it does eat up
a lot of extra lines that only have braces on them, which cuts down on
the density of code you can view easily on a single screen.

Then again, I also see and feel similarity between my formatting of C
in:

if (stuff) {
do something
} else {
do something else
}

and my Python:

if stuff:
do something
else:
do something else

is in terms of indentation and line position of portions of the flow
control. The only brace in the C code that unnecessarily adds lines
is the final closing one. Of course I'm sure the same argument could
be worded about the other popular formats. To each his own :-)

-- David

[Gary Herron]

On Wednesday 07 July 2004 01:28 pm, bruno modulix wrote:

Jacek Generowicz a écrit :

"Sateesh" <ex****************@nokia.com> writes:

Hi,
I am a beginner in Python, and am wondering what is it about the
indentation in Python, without which python scripts do not work
properly.
Why can't the indentation not so strict so as to give better freedom to
the user?
Is there any plausible reason behind this?

It's this way because we (the Python community) feel VERY strongly
that this is the correct way to do it.

In any program in any language, one must maintain correct indentation
to make the program structure human-readable. (If you don't, you
should be fired immediately because no one, yourself included, will
ever be able to read your code.) Given that, why should any language
force us to maintain a second compiler readable method ("{" and "}" or
whatever) for specifying the program structure.

Having only one method of specifying program structure (and one which
is readable by both human and the compiler) makes sense. Indeed, many
of us have gotten to the point of believing that all those other
languages are simply WRONG and only Python has it CORRECT.

May you enjoy Python enough to get to the same level of understanding,
Gary Herron

[Leif K-Brooks]

bruno modulix wrote:

The fact is that there is no brace-and-indent-style-war with Python !-)

Seems to me like we're having one in this thread right now, even though
it's about a different family of languages.