Why Python style guide (PEP-8) says 4 space indents instead of 8 space??? 8 space indents ever ok??

[Christian Seberino]

Linux kernel style guide, Guido's C style guide and (I believe) old
K&R style recommends 8 SPACES for indent.

I finally got convinced of wisdom of 8 space indentation.

Guido also likes 8 space indentation FOR C CODE.

Why style guide (PEP-8) for Python says 4 space indents???

Is breaking rule to use 8 space indents everywhere
a REALLY bad idea??

I REALLY WANT TO DO MY OPEN SOURCE PYTHON PROJECT
WITH 8 SPACE IDENTS!!!!

Chris

[David C. Fox]

Christian Seberino wrote:

Linux kernel style guide, Guido's C style guide and (I believe) old
K&R style recommends 8 SPACES for indent.

I finally got convinced of wisdom of 8 space indentation.

Guido also likes 8 space indentation FOR C CODE.

Why style guide (PEP-8) for Python says 4 space indents???

Is breaking rule to use 8 space indents everywhere
a REALLY bad idea??

I REALLY WANT TO DO MY OPEN SOURCE PYTHON PROJECT
WITH 8 SPACE IDENTS!!!!

Chris

I don't have an official answer, but here are my guesses:

a)

In C, new lines are generally like any other white space (except within
strings, C++ // comments), so you can easily put new lines in the middle
of an expression.

In Python, newlines are significant, except within lists, tuples, etc.
and a few other cases, so you generally have to escape them with \
within statements. If you use 8-space indents in Python, you very
quickly end up having to escape a lot of new lines, which is annoying.

b)

Unless you have an editor which converts tabs to a fixed number of
spaces, typing 8 spaces is a pain. Even editors which do convert tabs
to spaces may not provide an easy way to un-indent by the same number of
spaces

--------

Of course, both these reasons would imply that 2 spaces was better than
4. Using 4 spaces was probably chosen as a compromise between points a)
and b) and making sure that the indentation level was clearly visible.

David

[Erik Max Francis]

Christian Seberino wrote:

I REALLY WANT TO DO MY OPEN SOURCE PYTHON PROJECT
WITH 8 SPACE IDENTS!!!!

You don't really think a style guide is going to stop you from doing
that, do you?

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Golf is a good walk spoiled.
\__/ Mark Twain

[Francis Avila]

"David C. Fox" <da*******@post.harvard.edu> wrote in message
news:FYDlb.2596$e01.5531@attbi_s02...

In Python, newlines are significant, except within lists, tuples, etc.
and a few other cases, so you generally have to escape them with \
within statements. If you use 8-space indents in Python, you very
quickly end up having to escape a lot of new lines, which is annoying.

As a side note, Python considers a tab to be == 8 spaces. So you can mix
spaces and tabs in a single file as long as you use an 8-space convention.
Now, if your editor displays \t as something other than 8 spaces (I think 8
is default in almost every editor, though), the indentation can LOOK wrong,
even though Python has no trouble with it!

Given that 4 spaces is overwhelmingly dominant in Python code, shouldn't
that behavior be changed, so that '\t'==' '*4?

Or perhaps python should have a heuristic, where the first first-level
indent in the file which is indented entirely by spaces establishes the
number of spaces that a tab character should be equivalent to.

(Or maybe it shouldn't, since mixing spaces and tabs is bound to cause
trouble eventually, and better to find out sooner than later...)
--
Francis Avila

[Peter Hansen]

Francis Avila wrote:

Given that 4 spaces is overwhelmingly dominant in Python code, shouldn't
that behavior be changed, so that '\t'==' '*4?

Or perhaps python should have a heuristic, where the first first-level
indent in the file which is indented entirely by spaces establishes the
number of spaces that a tab character should be equivalent to.

Anyone who believes there is or will be anything new in this discussion
hasn't been reading comp.lang.python or the mailing list nearly long enough.

Check the archives if you are having trouble falling asleep tonight,
and keep in mind the utter futility of writing anything more on this
subject (unless you just like to see yourself in print). :-)

-Peter

[Stan Graves]

se******@spawar.navy.mil (Christian Seberino) wrote in message news:<bf**************************@posting.google. com>...

Why style guide (PEP-8) for Python says 4 space indents???

Never heard of that. I guess I need to read less about programming
and more about style. I use 2 space indents. Easy to type, easy to
change, and I'm never tempted to use tabs instead...

--Stan Graves
st**@SoundInMotionDJ.com
http://www.SoundInMotionDJ.com

[Martin v. Löwis]

so*************@yahoo.com (Stan Graves) writes:

Never heard of that. I guess I need to read less about programming
and more about style. I use 2 space indents. Easy to type, easy to
change, and I'm never tempted to use tabs instead...

In non-Python-aware editors (like Usenet messages), I prefer 2-space
indentation as well. While programming larger projects, I use a
Python-aware editor, and that editor makes indentation automatically
(to four spaces), so it is just as easy to type.

Regards,
Martin

[Paul Boddie]

Erik Max Francis <ma*@alcyone.com> wrote in message news:<3F***************@alcyone.com>...

Christian Seberino wrote:

I REALLY WANT TO DO MY OPEN SOURCE PYTHON PROJECT
WITH 8 SPACE IDENTS!!!!

You don't really think a style guide is going to stop you from doing
that, do you?

Keep looking over your shoulder! Only if you expect the (style guide)
Spanish Inquisition, will they never show up. That's your only
protection if you're an eight spaces heretic. ;-)

Paul

P.S. Seriously, most people respect the indentation of the project
"lead" on open source projects - for example, Webware employs hard
tabs throughout its source code, and yet very few people go in and
mangle the code with two space indents and other such misdemeanours.
Some people claim some kind of inherent superiority with "whitespace
insensitive" languages, but I imagine that they are members of that
irritating club who go into C++ files and trash the indentation,
claiming that "it looks OK in Visual Studio". I suppose that this is
another area where Python almost inadvertently encourages more
considerate programming practices.

[John Roth]

"Francis Avila" <fr***********@yahoo.com> wrote in message
news:vp************@corp.supernews.com...

"David C. Fox" <da*******@post.harvard.edu> wrote in message
news:FYDlb.2596$e01.5531@attbi_s02...

In Python, newlines are significant, except within lists, tuples, etc.
and a few other cases, so you generally have to escape them with \
within statements. If you use 8-space indents in Python, you very
quickly end up having to escape a lot of new lines, which is annoying.

As a side note, Python considers a tab to be == 8 spaces. So you can mix
spaces and tabs in a single file as long as you use an 8-space convention.
Now, if your editor displays \t as something other than 8 spaces (I think

8 is default in almost every editor, though), the indentation can LOOK wrong, even though Python has no trouble with it!
I considered not dropping into this conversation, since Peter Hanson's
reply is absolutely correct - the subject is dead and won't be revisited.
However, there are two errors in the previous paragraph that I think
need to be addressed.

First, Python, along with most xNIX sofware, considers a tab to
be an instruction to move to the next column that is a multiple of 8
(or 8 + 1 if you're starting at 0.)

It's also regarded as ***VERY*** bad practice to mix spaces
and tabs for indentation, and you are guaranteed to get bad results
if you move between editors that have the default number of spaces
to generate for tabs set to something different. In fact, the ability
to use tabs at all for indentation may very well vanish in Python
3.0 (although not sooner.)
Given that 4 spaces is overwhelmingly dominant in Python code, shouldn't
that behavior be changed, so that '\t'==' '*4?

Or perhaps python should have a heuristic, where the first first-level
indent in the file which is indented entirely by spaces establishes the
number of spaces that a tab character should be equivalent to.
Historically, Python has had the ability to identify the footprint that
a number of popular editors leave in the file. This has never been
documented, and since I don't use emacs, I don't know if it's still
in the current version of Python. It may not be, since it's only useful
if you mix tabs and spaces, and that's been identified as bad practice.
It's also not completely compatible with the character set comment
in 2.3
(Or maybe it shouldn't, since mixing spaces and tabs is bound to cause
trouble eventually, and better to find out sooner than later...)
Most editors can be set to generate spaces when you use the
tab key. It's the recommended practice with Python.

John Roth

--
Francis Avila

[Hung Jung Lu]

Peter Hansen <pe***@engcorp.com> wrote in message news:<3F***************@engcorp.com>...

Anyone who believes there is or will be anything new in this discussion
hasn't been reading comp.lang.python or the mailing list nearly long enough.

Yeah, the eternal, never-ending war between the tabibans and the tabifans.

Hung Jung

[Oren Tirosh]

Some tabs are 8 space wide
But spaces don't cost any money
Other tabs leap 4 in one stride
They make my source code look funny

[Peter Hansen]

Hung Jung Lu wrote:

Peter Hansen <pe***@engcorp.com> wrote in message news:<3F***************@engcorp.com>...

Anyone who believes there is or will be anything new in this discussion
hasn't been reading comp.lang.python or the mailing list nearly long enough.

Yeah, the eternal, never-ending war between the tabibans and the tabifans.

Careful. I think you've just attracted the attention of the Bush war machine...

:-)

-Peter

[Aahz]

In article <m3************@mira.informatik.hu-berlin.de>,
Martin v. =?iso-8859-15?q?L=F6wis?= <ma****@v.loewis.de> wrote:

In non-Python-aware editors (like Usenet messages), I prefer 2-space
indentation as well. While programming larger projects, I use a
Python-aware editor, and that editor makes indentation automatically
(to four spaces), so it is just as easy to type.

Get a better newsreader. ;-) (My newsreader lets me pick any editor I
want.)
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan

[JanC]

aa**@pythoncraft.com (Aahz) schreef:

Get a better newsreader. ;-) (My newsreader lets me pick any editor I
want.)

And Martin uses an editor as his newsreader... :-p

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

[Michael Hudson]

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

Hung Jung Lu wrote:

Peter Hansen <pe***@engcorp.com> wrote in message news:<3F***************@engcorp.com>...

Anyone who believes there is or will be anything new in this discussion
hasn't been reading comp.lang.python or the mailing list nearly long enough.

Yeah, the eternal, never-ending war between the tabibans and the tabifans.

Careful. I think you've just attracted the attention of the Bush war machine...

We have always been at war with FourSpaceTabania!

Cheers,
mwh

--
"Also, does the simple algorithm you used in Cyclops have a name?"
"Not officially, but it answers to "hey, dumb-ass!"
-- Neil Schemenauer and Tim Peters, 23 Feb 2001

[Stephen Horne]

On Wed, 22 Oct 2003 16:16:15 -0700, Erik Max Francis <ma*@alcyone.com>
wrote:

Christian Seberino wrote:

I REALLY WANT TO DO MY OPEN SOURCE PYTHON PROJECT
WITH 8 SPACE IDENTS!!!!

You don't really think a style guide is going to stop you from doing
that, do you?

Exactly.

My advice is basically do what suits you. Just do it consistently.

Personally, I prefer two space indents. I'm just too lazy to type any
more if I can avoid it. But when editing existing code, in any
language, I just go with what's already there - as long as there is
some consistent indentation rule evident, anyway.
Are there any tools which can intelligently redo the indentation in a
Python source file? Preferably respecting other formatting conventions
where practical, though of course I accept that no program could
replace a programmer with an eye for readability in this respect.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Dave Kuhlman]

Stephen Horne wrote:

[snip]

Are there any tools which can intelligently redo the indentation
in a Python source file? Preferably respecting other formatting
conventions where practical, though of course I accept that no
program could replace a programmer with an eye for readability in
this respect.

If you are on Linux/UNIX or have access to the cygwin tools on MS
Windows, then try:

unexpand -4 orig.py > tmp.py
expand -2 tmp.py > dest.py

to convert from 4-space indents to 2-space indents, and

unexpand -2 orig.py > tmp.py
expand -4 tmp.py > dest.py

to convert from 2-space indents to 4-space indents.

But, it does seem like a lot of trouble to go through just so that
people will look at your code and say "Eewh! Why didn't s/he read
the style guide?" Or maybe they will smirk and say, "I'll bet s/he
uses an editor in which the Tab key doesn't work, ... something
like Notepad on MS Windows. I pity the fool."

Also, if you have the Python source distribution, look at
Tools/scripts/untabify.py. Also, in the string module (in the
standard library) and the string data type, look at the
expandtabs() method.

Except, I don't know what these do with tabs in quoted strings.
The default behavior of unexpand is to convert only
characters at the beginning of each line. With expand, use the -i
option to convert only initial tabs.

Next, ask yourself the following questions: Why is there no
Tools/scripts/tabify.py? And, why is there no string.unexpandtabs()
method? Could there be a conspiracy to take away your right to
use tabs?

Dave

--
Dave Kuhlman
http://www.rexx.com/~dkuhlman
dk******@rexx.com

[Erik Max Francis]

Dave Kuhlman wrote:

If you are on Linux/UNIX or have access to the cygwin tools on MS
Windows, then try:

unexpand -4 orig.py > tmp.py
expand -2 tmp.py > dest.py

to convert from 4-space indents to 2-space indents, and

unexpand -2 orig.py > tmp.py
expand -4 tmp.py > dest.py

to convert from 2-space indents to 4-space indents.

Blasphemy! Use a pipe and avoid the need for the temporary file
altogether:

unexpand -4 orig.py | expand -2 > dest.py

etc.

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ To endure what is unendurable is true endurance.
\__/ (a Japanese proverb)

[Steve Williams]

Stephen Horne wrote:
[snip]

Are there any tools which can intelligently redo the indentation in a
Python source file? Preferably respecting other formatting conventions
where practical, though of course I accept that no program could
replace a programmer with an eye for readability in this respect.

..../Python.../Tools/Scripts/reindent.py

[Harry George]

Stephen Horne <st***@ninereeds.fsnet.co.uk> writes:

On Wed, 22 Oct 2003 16:16:15 -0700, Erik Max Francis <ma*@alcyone.com>
wrote:

Christian Seberino wrote:

I REALLY WANT TO DO MY OPEN SOURCE PYTHON PROJECT
WITH 8 SPACE IDENTS!!!!
You don't really think a style guide is going to stop you from doing
that, do you?

Exactly.

My advice is basically do what suits you. Just do it consistently.

Personally, I prefer two space indents. I'm just too lazy to type any
more if I can avoid it. But when editing existing code, in any
language, I just go with what's already there - as long as there is
some consistent indentation rule evident, anyway.

If you never work with others, never edit code from others, and never
offer code to the OSS world, then I suppose you can do your own indent
rules. But for those of us in the connected world (and esp. those
doing XP), playing by the 4-char rule is crucial.

So the question is: How can you do the correct indents everytime,
without having to manually count them out? You should be using an
editor which understands python indents (e.g., emacs with
python-model.el). Even vi and nedit can be set up to understand
4-char indents.


Are there any tools which can intelligently redo the indentation in a
Python source file? Preferably respecting other formatting conventions
where practical, though of course I accept that no program could
replace a programmer with an eye for readability in this respect.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

--
ha************@boeing.com
6-6M31 Knowledge Management
Phone: [phone]

[Stephen Horne]

On Mon, 27 Oct 2003 08:36:04 GMT, Harry George
<ha************@boeing.com> wrote:

If you never work with others, never edit code from others, and never
offer code to the OSS world, then I suppose you can do your own indent
rules.

That is emphatically *not* my situation. OK, I've made no significant
contribution to the open source world (yet) but as a professional
programmer, working with code that was produced by someone else (and
usually maintained by a number of people), and writing code to be read
by someone else is just a basic fact of everyday life.

My experience is that the size of indent really doesn't make much
difference as long as it is consistent in each file - you get roughly
the same number of complaints no matter what length you choose.

At work, there isn't really a set rule that I'm aware of. Most people,
when creating a new file, tend to go with either two or four space
indents, though there are a couple of eight-spacers too, but it really
isn't a big thing. It doesn't create unreadable chaos, it just means
some files have wider indents than others.

And yes, any half-decent editor can be set up to indent properly to
any width. Mine are set up to use two space indents. But because I
also regularly end up using new editors (which I've not yet figured
out how to set up correctly), or simple editors (sometimes notepad
does the job simply because it is there) or editors set to someone
elses preferences, or files which use indent levels different to my
preferences, my habit is to avoid the tab key altogether and just use
the space key. That way, if I forget that a particular editor has not
yet been set up to use spaces instead of tabs, I don't get a file
using mixed tabs and spaces for instance.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Harry George]

Stephen Horne <st***@ninereeds.fsnet.co.uk> writes:

On Mon, 27 Oct 2003 08:36:04 GMT, Harry George
<ha************@boeing.com> wrote:

If you never work with others, never edit code from others, and never
offer code to the OSS world, then I suppose you can do your own indent
rules.
That is emphatically *not* my situation. OK, I've made no significant
contribution to the open source world (yet) but as a professional
programmer, working with code that was produced by someone else (and
usually maintained by a number of people), and writing code to be read
by someone else is just a basic fact of everyday life.

My experience is that the size of indent really doesn't make much
difference as long as it is consistent in each file - you get roughly
the same number of complaints no matter what length you choose.

At work, there isn't really a set rule that I'm aware of. Most people,
when creating a new file, tend to go with either two or four space
indents, though there are a couple of eight-spacers too, but it really
isn't a big thing. It doesn't create unreadable chaos, it just means
some files have wider indents than others.

And yes, any half-decent editor can be set up to indent properly to
any width. Mine are set up to use two space indents. But because I
also regularly end up using new editors (which I've not yet figured
out how to set up correctly), or simple editors (sometimes notepad
does the job simply because it is there) or editors set to someone
elses preferences, or files which use indent levels different to my
preferences, my habit is to avoid the tab key altogether and just use
the space key. That way, if I forget that a particular editor has not
yet been set up to use spaces instead of tabs, I don't get a file
using mixed tabs and spaces for instance.

You can get away with file-by-file decisions in some languages, but
not python. As you refactor code among files, and as you do Extreme
Programming with someone using a different editor, you will kill
productivity if you are fussing with indents. Go with the guidleines
and that pain from "accidental complexity" (Brooks term) disappears.

--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

--
ha************@boeing.com
6-6M31 Knowledge Management
Phone: [phone]