Python indentation

[Antoon Pardon]

Antoon> I would prefer to indent sucu code as follows:

Antoon> while True:
Antoon> code
Antoon> if condition: break
Antoon> code


Antoon> Why? because the loopbreaker is IME part of the
Antoon> loopstructure, not an ordinary if statement in the
Antoon> loopbody.

It's still going against the underlying block structure, so a source
code "prettifier" would screw it up even if Python allowed it.

That is the reason I don't use prettifier. Indentation IMO should
illustrate the logic of the algorithm, not the structure of language
you wrote the algorithm in. Sure these two often go together but
sometimes they don't. In that case I find it a real pain that
python forces me to illustrate the structure of the language
and not the structure of the algorithm like when you have a
loop with the termination condition not at the top.

Python23/Tools/Scripts/pindent.py (DOS)
/usr/share/doc/python2.3/examples/Tools/scripts/pindent.py (Debian)

Antoon> This is why I prefer free form languages. If you need
Antoon> certain control structure that is not directly in the
Antoon> language but can be simulated, you can still indent your
Antoon> code according to the structure you have in mind as
Antoon> opposed to the structure that is forced upon you by the
Antoon> simulation.

You realize that this approach is slightly heretical, do you?
Indentation should follow the "real" block structure *exactly*,
anything else is an error that confuses the reader.

Why should the indentation follow the block structure instead of
structure of the algorithm

The while 1 - break structure doesn't even need extra clarification,
because the break is typically in a very idiomatic place - right after
the assignment in the beginning, or at the very end if it's
semantically a repeat-until loop (which are rare).

I have loops that don't conform to the above description. Like
the following.

loop
shift = 0
delta = 1
full = 1L
while (self.bits & full) == 0:
full = (full << delta) + full
shift = delta
delta = delta * 2
breakif shift == 0:
self.offset = self.offset + shift
self.bits = self.bits >> shift


And this is just a simple example. Indented like I did here,
clearly shows where the loopbreaker occurs, which is less
clear when loopbreaker is indented the same way as the rest
of the loop.

So why should I be forced to indent in a way that doesn't
reflect the structure of the algorithm, simply because
the language is not rich enough.

 

[Xavier Combelle]

If you are used to coding in vi editor, it supports C (or for that matter
any language that uses braces) well. I feel the biggest advantage of using
braces is that I can know the start and end of the block of code, and this
becomes important if the code block is big and does not fit your screen. All
I need to do is to place the cursor on the { or } and press the key
combination shift+%. This will show the start and the end brace for that
block. And if there is an error, you will clearly know that using this key
combination. I have been using this method all the time, and it proved to be
really effective.

IMO, shift+% is very useful in C. That's why I prefer editing C code
with vi. But the point is that since I use Python I never had any
problems to understand where is the begin and the end of the current
block. I suppose it's because Python is far more concise and help to
factor the code.
I prefer wonderful editor options when they are not necessary.

Xavier

 

[Thomas Bellman]

Yes. Name the number of spaces a TAB should translate into.

Up to the next tab stop, and tab stops are placed at every 8th
column. No more, no less.

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

Because that's the way it has been since time eternal. Every
terminal I have seen have had tab stops at every 8th column.
Every printer I have encountered does the same (if it supports
plain text ASCII, that is; EBCDIC printers is of course a
different matter, but Python doesn't support EBCDIC anyway).

TAB, by it's very nature, is a variable and
configurable width.

The character code 91 (decimal) is by its very nature configurable
what it means. For instance, some years ago here in Sweden it
was popular to configure your display device to show it as a
capital letter A with diaresis. Yet, Python absolutely believes
that it is an opening square parenthesis.

The fact that some people are doing broken things (configuring
their editors to have tab stops at other than every 8th column)
is not enough for me to give up tabs. It is *their* problem if
they do such stupid things.

 

[David Fraser]

Why should the indentation follow the block structure instead of
structure of the algorithm


I have loops that don't conform to the above description. Like
the following.

loop
shift = 0
delta = 1
full = 1L
while (self.bits & full) == 0:
full = (full << delta) + full
shift = delta
delta = delta * 2
breakif shift == 0:
self.offset = self.offset + shift
self.bits = self.bits >> shift

And this is just a simple example. Indented like I did here,
clearly shows where the loopbreaker occurs, which is less
clear when loopbreaker is indented the same way as the rest
of the loop.

So why should I be forced to indent in a way that doesn't
reflect the structure of the algorithm, simply because
the language is not rich enough.

The fact that the block structure doesn't match the structure of the
algorithm is what you are finding a problem here. What you really want
is a different loop construction.

But I personally find the above code hard to read - it takes a lot of
thinking to try and work out what you are trying to do here whichever
way you indent it. I think your indentation actually confuses the issue more

David

 

[Antoon Pardon]

The fact that the block structure doesn't match the structure of the
algorithm is what you are finding a problem here. What you really want
is a different loop construction.

Well that would of course be the best solution. But in absence
of a more general loop construction I'm willing to settle for
a construction that looks like it, even if it has to be
simulated.

But I personally find the above code hard to read - it takes a lot of
thinking to try and work out what you are trying to do here whichever
way you indent it. I think your indentation actually confuses the issue more

Maybe you are just not familiar with more general loop constructs.

What the algorithm is trying to do is find the least significant bit
that is on. It does so by applying succeeding masks to the number
each mask is all ones and double in length as the previous mask.
when applying a mask results in a number different from 0, the
number is shifted the length of the previous mask and the length
is added to the offset. The process is then repeated with the
mask initialized at 1. The algorthm stops when applying a mask
of 1 already differs from 0.

 

[Istvan Albert]

Uhm, yes, it is. With vim part of my configuration when loading Python

<snip> a lot of vi configuration

So let me get this straight, you researched all that to
make your editor work as if you were inserting tabs in
the first place....

You know what you are?

A closet tabber. You want the tab yet you want to fit in
with the space folks.

i.

 

[Christopher T King]

Well personnaly if i have a loop with the terminating condition
in the middle I now have to write it like this

while True:
code
if condition: break
code


I would prefer to indent sucu code as follows:

while True:
code
if condition: break
code


Why? because the loopbreaker is IME part of the loopstructure,
not an ordinary if statement in the loopbody.

Then perhaps you'd be interested in PEP 315:

do:
code
while not condition:
code

Much more readable than improperly indented ifs, IMHO.

 

[Steve Lamb]

Up to the next tab stop, and tab stops are placed at every 8th
column. No more, no less.

Bzt. Next.

Because that's the way it has been since time eternal. Every
terminal I have seen have had tab stops at every 8th column.

But we're not talking terminals. Nice try, you lose.

 

[Steve Lamb]

So let me get this straight, you researched all that to
make your editor work as if you were inserting tabs in
the first place....

No, actually. I did a google search for "vim python options" and picked
one that seemed sensible.

You know what you are?

Better at playing with the other kiddies than you are?

A closet tabber. You want the tab yet you want to fit in
with the space folks.

Uh, nope. You'll never once find me arguing in favor of tabs no matter
what the code. I have been using spaces for indenting my code since I first
started with Turbo Pascal 3 about 20 years ago. C? Space indented. Perl?
Space indented. Python? Space indented. HTML? Space indented. PHP? Space
indented. 4DOS & 4OS/2? Space indented. Quite frankly outside of variable
space documents I feel the tab as a character should no longer exist.

 

[Steve Lamb]

Well personnaly if i have a loop with the terminating condition
in the middle I now have to write it like this

while True:
code
if condition: break
code

I would prefer to indent sucu code as follows:

while True:
code
if condition: break
code

In both cases you should get a stern talking to in either case. Why?
Make condition really long.

while 1:
do(a_thing)
if (some_really_long_thing > some_other_long_thing): break
do(something)

It isn't obvious that the if is doing anything.

while 1:
do(a_thing)
if (some_really_long_thing > some_other_long_thing):
break
do(something)

Oh, look, the if does something there. The idention and block, even though
it is a single-line block, tells us at a glance what is going on. The code is
better comprehended that way. Your way, both of them, only serves to confuse.

 

[Tor Iver Wilhelmsen]

Up to the next tab stop, and tab stops are placed at every 8th
column. No more, no less.

I think you mean the 8th column of the punch card, old timer.

Because that's the way it has been since time eternal.

It has been that way for punch cards and Fortran-programmers using
Teletypes (the early paper-based character terminals that the "tty"
term in Unix comes from).

Every terminal I have seen have had tab stops at every 8th column.

As well they should; a lot of ancient software depends on it.

Every printer I have encountered does the same (if it supports plain
text ASCII, that is; EBCDIC printers is of course a different
matter, but Python doesn't support EBCDIC anyway).

As well they should; a lot of ancient software depends on it.

The character code 91 (decimal) is by its very nature configurable
what it means. For instance, some years ago here in Sweden it was
popular to configure your display device to show it as a capital
letter A with diaresis. Yet, Python absolutely believes that it is
an opening square parenthesis.

Much like a TAB meaning tab stop every 8 characters, the ISO 646 you
refer to is DEAD - except for the one map that corresponds to US
ASCII.

The fact that some people are doing broken things (configuring their
editors to have tab stops at other than every 8th column) is not
enough for me to give up tabs. It is *their* problem if they do such
stupid things.

No.

Let me guess, you hated the advancement of proportional fonts as well?

 

[Dan Bishop]

Tor Iver Wilhelmsen a écrit :

Quite easy :
#define BEGIN {
#define END }

Yeah, but Pascal is case-insensitive, so you have to write:

#define begin {
#define Begin {
#define bEgin {
#define BEgin {
#define beGin {
#define BeGin {
// etc.

 

[Christopher T King]

Let me guess, you hated the advancement of proportional fonts as well?

Do you use proportional fonts when you're programming?

 

[Mark 'Kamikaze' Hughes]

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

foo
bar
baz
quux
wibble
pting

One of those indentation levels is not like the others. Guess which
one!

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.

You think wrong. Basically every programmer's editor does that, quite
easily, and has for decades--it's been at least 20 years since I've seen
an editor that didn't.

In Vim:
set sw=4 sta et ai bs=2

Put that in your .vimrc, and you're done. The key labelled Tab is now
just a convenient way of specifying "indent the standard four spaces",
and backspace on leading spaces removes the last four. Done.

Nobody would accuse Vim of being the easiest editor in the world to
learn or configure, but you learn that the way you learn anything about
it: you ask a local guru who tells you, or you type :help just like it
says when it starts up without a file.

Other editors are easier--less powerful, but easier. Most come with
that behavior turned on by default, or with a pretty checkbox option on
their pretty GUI option page.

You have confused tabulation, which is an ancient display hack for
terminals, with indentation, which is a representation of nesting depth.
They're separate concepts. You can use tabulation for indentation, but
as my example above shows, that's very error-prone.

 

[Steve Lamb]

foo
bar
baz
quux
wibble
pting

One of those indentation levels is not like the others. Guess which
one!

Becomes kinda obvious when one quotes, don't it?

 

[Stephen Ferg]

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

I absolutely agree. Count me as a long-term member in the tabbers camp.

 

[Peter Hansen]

Becomes kinda obvious when one quotes, don't it?

I'm not sure... both of them look the same in Netscape...

 

[Chris Share]

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.

FYI, it's pretty simple...

I use vim for writing python in, with the following options:
:set et
:set tabstop=4

The first one tells it to replace tabs by spaces, the second that a tab
should be 4 characters, which I find to be a comfortable indenting level
- 2 spaces doesn't look clear enough, and 8 spaces gets pretty annoying
with more than one or two indents deep.

chris

 

[Antoon Pardon]

Then perhaps you'd be interested in PEP 315:

do:
code
while not condition:
code

Yes, and I would also be interested in an other proposal
that went something like:


while condition1:
code
and while condition2:
code
and while condition3:
code



maybe we should combine them into something like

do:
code
and while condition1:
code
and while condition3:
code

Much more readable than improperly indented ifs, IMHO.

Sure, but since I mostly do this in C, I use a macro
so it doens't look like an if.

 

[=?iso-8859-15?Q?Pierre-Fr=E9d=E9ric_Caillaud?=]

Scite has space mode and tab mode.
In space mode, hitting Tab inserts N spaces, hitting DEL removes N spaces.
In tab mode, it works as expected.
You can indent/dedent whole blocks with tab/shift-tab.
Other editors do it, too. Any editor not doing this is ridiculous IMHO.
It understands Python, so it will indent after if: else: for: etc. You
never use the TAB key only the DEL key

I still use tabs...