Python indentation

Op 2004-07-07, Brian Quinlan schreef <br***@sweetapp.com>:

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:

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.

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

--
Antoon pardon

Jul 18 '05 #56

Op 2004-07-07, Reinhold Birkenfeld schreef <re************************@wolke7.net>:

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.

My experience is otherwise.

--
Antoon Pardon

Jul 18 '05 #57

Alan Gauld

On 07 Jul 2004 19:50:03 -0400, David Bolen <db**@fitlinxx.com>
wrote:

Clearly it's an "in the eye of the beholder" thing. I will admit to
being a K&R "one true brace style" guy.

Actually its not just an "eye of the beholder thing". McConnell
discusses this in his Code Complete book and cites studies that
showed that the style that most programmers preferred was not the
style that led to best comprehension.

As a result of that I changed my C style from

if (foo)
{
doit()
}
else
{
doAnother()
}

Which had been the preferred style in McConnels reference study
To

if (foo) {
doit()
}
else {
doAnother()
}

Then I changed my "style" even more radically to:

if foo:
do it()
else:
doAnother

Both of which matched McConnels best practice, but the Python one
gave me no cosmetics versus comprehension debate... :-)

Alan G.

Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

Jul 18 '05 #58

Alan Gauld

On Thu, 08 Jul 2004 06:09:45 GMT, "Sateesh"
<ex****************@nokia.com> wrote:

I am just wondering, how huge if, else blocks of code can be easily handled
in python.

Given that modern editors typically display 50-100 lines of code
at a time its not been a big problem. Also given the much higher
level of code in Python vv C you don't get so many huge blocks.
Finally if you regularly come across blocks of code more than 50
lines long then I think its probably time to start refactoring
that code! :-)

In fact the longest indented blocks I find are class definitions.
Those can be several hundred lines long and it can be hard to
know which class you are reading if several big classes exist
inside a module. It's one area where I wish Python had adopted
the Delphi interface/implementation style where the class
interface isb published and the individuial methods are
implemented separately

class C
def __Init__(a,b,c): pass
def f(d): pass
def g(): pass

implementation: <---- New keyword or something?

def C.__Init__(a,b,c)
# initialise here

def C.f()
# real code here

def C.g():
# and here

But thats for another topic I guess... :-)
Alan G.
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld

Jul 18 '05 #59

Ville Vainio

>>>>> "Antoon" == Antoon Pardon <ap*****@forel.vub.ac.be> writes:

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.

BTW, every time this indentation issue comes up I'd like to point
people to pindent.py in Tools/scripts directory. It augments source
with block closing comment (and vice versa), like this:

def foobar(a, b):
if a == b:
a = a+1
elif a < b:
b = b-1
if b > a: a = a-1
# end if
else:
print 'oops!'
# end if
# end def foobar

The script is either in:

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.

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

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

Jul 18 '05 #60

Op 2004-07-08, Ville Vainio schreef <vi***@spammers.com>:

>> "Antoon" == Antoon Pardon <ap*****@forel.vub.ac.be> writes:

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.

--
Antoon Pardon

Jul 18 '05 #61

Xavier Combelle

Sateesh wrote:

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

Jul 18 '05 #62

Thomas Bellman

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

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.
--
Thomas Bellman, Lysator Computer Club, Linköping University, Sweden
"I don't think [that word] means what you ! bellman @ lysator.liu.se
think it means." -- The Princess Bride ! Make Love -- Nicht Wahr!

Jul 18 '05 #63

Grant Edwards wrote:

In article <2l************@uni-berlin.de>, Leif K-Brooks 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.

That just goes to show you how great Python is. We have to
talk about other languages to have a good argument.

QOTW! :)

Jul 18 '05 #64

Op 2004-07-08, David Fraser schreef <da****@sjsoft.com>:

Antoon Pardon wrote:
Op 2004-07-08, Ville Vainio schreef <vi***@spammers.com>:
/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.

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.

--
Antoon Pardon

Jul 18 '05 #65

Istvan Albert

Steve Lamb wrote:

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.

Jul 18 '05 #66

On 8 Jul 2004, Antoon Pardon wrote:

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.

Jul 18 '05 #67

On 2004-07-08, Thomas Bellman <be*****@lysator.liu.se> wrote:

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 C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

Jul 18 '05 #68

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

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 C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

Jul 18 '05 #69

On 2004-07-08, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:

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.

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

Jul 18 '05 #70

Tor Iver Wilhelmsen

Thomas Bellman <be*****@lysator.liu.se> writes:

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?

Jul 18 '05 #71

Dan Bishop

bruno modulix <on***@xiludom.gro> wrote in message news:<40***********************@news.free.fr>...

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 }

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

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

:-)

Jul 18 '05 #72

On 8 Jul 2004, Tor Iver Wilhelmsen wrote:

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

Do you use proportional fonts when you're programming?

Jul 18 '05 #73

Mark 'Kamikaze' Hughes

Istvan Albert <ia*****@mailblocks.com>
wrote on Wed, 07 Jul 2004 17:13:38 -0400:

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?

foo
bar
baz
quux
wibble
pting

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

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

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.

--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"The void breathed hard on my heart, turning its illusions to ice, shattering
them. Was reborn, then, free to scrawl own design on this morally blank
world. Was Rorschach." --Alan Moore, _Watchmen #6_, "The Abyss Gazes Also"

Jul 18 '05 #74

On 2004-07-08, Mark 'Kamikaze' Hughes <ka******@kuoi.asui.uidaho.edu> wrote:

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? :)

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

Jul 18 '05 #75

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.

Jul 18 '05 #76

Steve Lamb wrote:

On 2004-07-08, Mark 'Kamikaze' Hughes <ka******@kuoi.asui.uidaho.edu> wrote:
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? :)

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

Jul 18 '05 #77

Chris Share

On Wed, 07 Jul 2004 18:36:05 -0400, Peter Hansen <pe***@engcorp.com> wrote:

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

Jul 18 '05 #78

Op 2004-07-08, Christopher T King schreef <sq******@WPI.EDU>:

On 8 Jul 2004, Antoon Pardon wrote:
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

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.

--
Antoon Pardon

Jul 18 '05 #79

Pierre-Frédéric 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...

Jul 18 '05 #80

Pierre-Frédéric Caillaud

Do you use proportional fonts when you're programming?

Yes, of course.

Jul 18 '05 #81

Antoon Pardon wrote:

Op 2004-07-08, Christopher T King schreef <sq******@WPI.EDU>:
On 8 Jul 2004, Antoon Pardon wrote:

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

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

The trouble like this is I can't see what it means... it actually reads
like concurrent execution - 'do this and this and this...'
So I don't think its very readable...

David

Jul 18 '05 #82

Antoon Pardon wrote:

Op 2004-07-08, David Fraser schreef <da****@sjsoft.com>:
Antoon Pardon wrote:
Op 2004-07-08, Ville Vainio schreef <vi***@spammers.com>:
/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.

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.

The thing is, the readability is lost if what it looks like is different
to what it actually does. Anyway, you can't do that using Python because
of the indentation of the language so if you want to you'll have to use
another language :-)

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.

Sure, but I didn't find the loop structure itself readable. Maybe just a
matter of what some people like others don't.

Jul 18 '05 #83

Antoon Pardon wrote:

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

As with David, I have no idea what these are supposed to do.
Could you please translate them into the existing Python
loop idiom (while,if/break etc) so that those of us who can't
read minds can understand what the above constructs are
intended to do?

-Peter

Jul 18 '05 #84

On 8 Jul 2004, Mark 'Kamikaze' Hughes wrote:

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.

I dunno... that looks like some kind of voodoo chant to me... ;)

Jul 18 '05 #85

Paramjit Oberoi

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

Andrew Koenig proposed this in the following email:

http://groups.google.com/groups?q=g:...search.att.com

If link doesn't work - it was a post dated 2003-05-05 with the subject
"Re: PEP 315: Enhanced While Loop". There was a fairly long thread about
it back then.

Jul 18 '05 #86

Paramjit Oberoi wrote:

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

Andrew Koenig proposed this in the following email:

http://groups.google.com/groups?q=g:...search.att.com

If link doesn't work - it was a post dated 2003-05-05 with the subject
"Re: PEP 315: Enhanced While Loop". There was a fairly long thread about
it back then.

A quote from the message: while <condition1>:
<code1>
and while <condition2>:
<code2>
and while <condition3>:
<code3>

[snip] would be equivalent to

while <condition1>:
<code1>
if not (<condition2>): break
<code2>
if not (<condition3>): break
<code3>

The thing is, to me as an English speaker, there is no logical
correlation between the proposed syntax and its semantics.
For example, why shouldn't code3 be executed if condition2 is false and
condition3 is true?

David

Jul 18 '05 #87

Josef Meile

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

if (condition) {
doThis();
doThat();
} else {
doWhatever();
andSoOn();
} I don't like that style. I think it's better to have the if and else at
the same level. ie:

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

Anyway, it's a matter of style :-)

which only takes 7 lines and is not much less readable. But I agree with
you!

I also agree. I love the fact that you can't produce bad indented code
in python

Regards,
Josef

Jul 18 '05 #88

On Fri, 9 Jul 2004, Josef Meile wrote:

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

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

I don't like that style. I think it's better to have the if and else at
the same level. ie:

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

Pfft. We all know real men drop the braces altogether and just do it like
this:

if (condition)
doThis(),
doThat();
else
doWhatever(),
andSoOn();

;)

Jul 18 '05 #89

Mark 'Kamikaze' Hughes

Christopher T King <sq******@WPI.EDU>
wrote on Fri, 9 Jul 2004 09:07:07 -0400:

On 8 Jul 2004, Mark 'Kamikaze' Hughes wrote:
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.

I dunno... that looks like some kind of voodoo chant to me... ;)

It can be written out in full:
set shiftwidth=4 smarttab expandtab autoindent backspace=indent,eol,start

I'm just an old-timey Vim geek, so I use the short version.

--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"The void breathed hard on my heart, turning its illusions to ice, shattering
them. Was reborn, then, free to scrawl own design on this morally blank
world. Was Rorschach." --Alan Moore, _Watchmen #6_, "The Abyss Gazes Also"

Jul 18 '05 #90

Josef Meile wrote:

I also agree. I love the fact that you can't produce bad indented code
in python

Well, if you try hard enough, you can still get pretty brutal:

a = 5

if a == 6: print '6'
else:
if a == 7:
print '7'
\
elif a \
== 8:
print '8'
else:
print 'none of the above'
;-)

-Peter

Jul 18 '05 #91

Paramjit Oberoi wrote:

Yes, and I would also be interested in an other proposal
that went something like:
while condition1:
code1
and while condition2:
code2
and while condition3:
code3

Andrew Koenig proposed this in the following email:

http://groups.google.com/groups?q=g:...search.att.com

If link doesn't work - it was a post dated 2003-05-05 with the subject
"Re: PEP 315: Enhanced While Loop". There was a fairly long thread about
it back then.

Andrew's interpretation doesn't fit mine. I look at
the above and wonder why the code2 block doesn't
continue to execute until condition2 fails, and then
the code3 block loops repeatedly until condition3
fails...

-Peter

Jul 18 '05 #92

Mark 'Kamikaze' Hughes

Paramjit Oberoi <p_********@hotmail.com>
wrote on Fri, 09 Jul 2004 09:12:42 -0500:

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

Andrew Koenig proposed this in the following email:
http://groups.google.com/groups?q=g:...search.att.com
If link doesn't work - it was a post dated 2003-05-05 with the subject
"Re: PEP 315: Enhanced While Loop". There was a fairly long thread about
it back then.

-1.

I do occasionally write loops where I do something, test and maybe
break, and then go on to do something else. However, the current while
construct does that just fine, and clearly expresses the start and end
of the code block:

linenum=1
while True:
line = raw_input()
if not line: break # or put on its own line, depending on taste
print "%05d:%s" % (linenum, line,)
linenum += 1

This confuses me as to where the loop starts and ends:
linenum=1
while True:
line = raw_input()
and while line:
print "%05d:%s" % (linenum, line,)
linenum += 1

I rarely use post-loop condition testing even in Java where it exists
and you can use assignment as an expression, let alone in Python. When
I do, an explicit if...break at the end works fine. Any loop that's
more than a few lines long, I usually extract into its own method.

--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"The void breathed hard on my heart, turning its illusions to ice, shattering
them. Was reborn, then, free to scrawl own design on this morally blank
world. Was Rorschach." --Alan Moore, _Watchmen #6_, "The Abyss Gazes Also"

Jul 18 '05 #93

Peter Hansen wrote:

Paramjit Oberoi wrote:
Yes, and I would also be interested in an other proposal
that went something like:
while condition1:
code1
and while condition2:
code2
and while condition3:
code3

Andrew Koenig proposed this in the following email:

http://groups.google.com/groups?q=g:...search.att.com
If link doesn't work - it was a post dated 2003-05-05 with the subject
"Re: PEP 315: Enhanced While Loop". There was a fairly long thread about
it back then.

Andrew's interpretation doesn't fit mine. I look at
the above and wonder why the code2 block doesn't
continue to execute until condition2 fails, and then
the code3 block loops repeatedly until condition3
fails...

Which is exactly why the syntax proposal is bad - there are too many
interpretations of what it might mean...

David

Jul 18 '05 #94

Nikola Plejic

Peter Hansen wrote:

Well, if you try hard enough, you can still get pretty brutal:

a = 5

if a == 6: print '6'
else:
if a == 7:
print '7'
\
elif a \
== 8:
print '8'
else:
print 'none of the above'

Living proof that you actually can write really bad-looking code in
Python. Brutal is just the correct word for code like this :).

Nice one ;).

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

Jul 18 '05 #95

Josef Meile

> Well, if you try hard enough, you can still get pretty brutal:

a = 5

if a == 6: print '6'
else:
if a == 7:
print '7'
\
elif a \
== 8:
print '8'
else:
print 'none of the above'
;-)

-Peter

Oh yes, I forgot that the backslash "\" could break the indentation. But
I think nobody would do this intentionally. The word "brutal" says it.

Anyway, a good way of offuscating code; although is not what I do :-)

Jul 18 '05 #96

Antoon Pardon wrote:

Op 2004-07-08, Ville Vainio schreef <vi***@spammers.com>:
/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.

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

Jul 18 '05 #97

Op 2004-07-09, Mark 'Kamikaze' Hughes schreef <ka******@kuoi.asui.uidaho.edu>:

Paramjit Oberoi <p_********@hotmail.com>
wrote on Fri, 09 Jul 2004 09:12:42 -0500:
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 Andrew Koenig proposed this in the following email:
http://groups.google.com/groups?q=g:...search.att.com
If link doesn't work - it was a post dated 2003-05-05 with the subject
"Re: PEP 315: Enhanced While Loop". There was a fairly long thread about
it back then.

-1.

I do occasionally write loops where I do something, test and maybe
break, and then go on to do something else. However, the current while
construct does that just fine, and clearly expresses the start and end
of the code block:

linenum=1
while True:
line = raw_input()
if not line: break # or put on its own line, depending on taste
print "%05d:%s" % (linenum, line,)
linenum += 1

This confuses me as to where the loop starts and ends:

This confusion may be nothing more than your unfamiliary which
such a construct.
linenum=1
while True:
line = raw_input()
and while line:
print "%05d:%s" % (linenum, line,)
linenum += 1

I rarely use post-loop condition testing even in Java where it exists
and you can use assignment as an expression, let alone in Python. When
I do, an explicit if...break at the end works fine.
That is not an argument. Before instructions like while, repeat etc
existed, we could use the equivallent of an if combined with a goto
and that worked fine too.
Any loop that's
more than a few lines long, I usually extract into its own method.

--
Antoon Pardon

Jul 18 '05 #98

Jacek Generowicz

Chris Share <us****@caesium.me.uk> writes:

On Wed, 07 Jul 2004 18:36:05 -0400, Peter Hansen <pe***@engcorp.com> wrote:
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

And how do I get it to send the function definition surrounding the
cursor to the Python interpreter with which it is currently
interacting ?

(Only half joking ... if there is a way to make vi(m) provide the same
interactive capabilities that Emacs does, then I would be able to
recommend it to those who insist on using vi in my courses and end up
trailing the rest of the class and slowing us all down.)

Jul 18 '05 #99